|Node||Protocol||Database||Release Date||Release Notes||GitHub Links|
|24.0||19||21||2023-01-19||V24.0||Release - Milestone - Changelog|
There are no database migrations or other upgrade considerations for this release.
Exchanges who have not faced issues with their nano nodes are recommended to await the arrival of V25.0.
In general, exchanges, services and integrations are encouraged 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.
Minor RPC breaking changes¶
There are three RPC calls with such changes:
accounts_representatives. For integrations using them, carefully review the additional details on these changes included in the RPC Updates section below.
Unit testing stability¶
One significant advancement for V24 is improved unit test stability and clarity. After older unit tests started failing intermittently, the node’s unit tests have been reviewed, documented and improved which has significantly aided subsequent development work.
V24 brings three major changes designed to improve bootstrap reliability:
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.
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.
A new bootstrapping algorithm that is statistical and more randomised is being worked on, 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.
In V23, the election scheduler process was added 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. An iterative improvement was made in this area, allowing our limited development resources to work on other advancements.
In addition to rebalancing the scheduler buckets, the scheduling algorithm was adjusted 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.
Unit tests and bug fixes¶
Another focus area was improving and cleaning up the unit tests, along with various minor bugs and fixes. Test runs are now more consistent and reliable with V23, and will continue to be improved on in the coming releases.
Improving and cleaning up the unit tests were still another focus area on V24, along with various minor bugs and fixes. Test runs are now more consistent and reliable, and will continue to be improved on in the coming releases.
Recent updates to naming conventions are noteworthy:
Receivable instead of pending¶
There were more updates on switching from the old term
receivable. These updates are considered to be complete in V24.0. As stated for V23.0, these changes can be seen in various areas of the node as well across many RPC calls. The backward compatibility has not been changed.
populate_backlogis a RPC command for populating backlog. Populating backlog is a process in the node that scans all accounts, checks for unconfirmed blocks in that account's chain and queues those blocks for confirmation via election scheduler.
accounts_representativesRPCs now return per account results making possible to them to retrieve partial data in case there is any error in one of the accounts. NOTE: There is a bug in the
accounts_balancesfeature, where it does not return zero balance or zero receivable for accounts that are not found. Instead, it returns an error. Additionally, returning an error message instead of the account details may disrupt the JSON parsing. The
accounts_representativescontain the same bug by mixing error data with the details. This issue will be addressed in a future release.
blocks_infoRPC now has a
receive_hashoption. This field facilitates retrieving the receive block of a specific send block.
receivableRPC now as an
offsetparameter that enables retrieving receivable blocks in chunks.
Pending/Receivable term RPC updates¶
There are various changes related to the switch from
receivable in RPC calls as noted above. Although all changes are backwards compatible, switching to the term
receivable in these cases is advised.
There are two main types of changes: RPC call name changes and updates to keys in the call requests and responses.
RPC call name changes
Response/request key changes only
wallet_ledgernow supports the
ledgernow supports the
block_infonow supports the
There are no breaking changes with this update, but switching to
receivable terms is advised.
confirmationtopic now has a
sidebandinfo for confirmed blocks
started_electionstopic has been added.
'all'to be specified by the
accountparameter to clear all the accounts
--helpnow displays the options in alphabetical order
- JSON serializing of config files are not supported anymore
- Updated to match
- Fixed bugs related to the pruned count and the unchecked count
- Updated to use the new Nano symbol
- Improves error logging for
- Improved election result logging
election.confirmedoutcome in log
Builds and commands¶
|Universal Linux||https://repo.nano.org/live/binaries/nano-node-V25.1-Linux.tar.bz2||SHA256 Checksum|
|Windows (exe)||https://repo.nano.org/live/binaries/nano-node-V25.1-win64.exe||SHA256 Checksum|
|Windows (zip)||https://repo.nano.org/live/binaries/nano-node-V25.1-win64.zip||SHA256 Checksum|
See Pulling the Docker Image for more details.
|RHEL/RockyLinux rpm||https://repo.nano.org/live/binaries/nanocurrency-25.1-1.el8.x86_64.rpm||SHA256 Checksum|