|Node||Protocol||Database||Release Date||Release Notes||GitHub Links|
|22.0||18||21||2021-05-14||V22.0||Release - Milestone - Changelog|
Known issue with RocksDB: RPC
unchecked_keys not working properly
Issue: The RPC
unchecked_keys is returning
0 for all calls when used with the RocksDB backend. This known issue will be resolved in a future release.
Solution: Until the issue is resolved any integrations using this command should remain on the existing LMDB backend
Database upgrades with increased disk requirements¶
Upgrade requires 150GB of free disk space
This version performs a database upgrade of the ledger format on disk. This process requires a large amount of disk space and due to the DoS attack on nano earlier in the year, the disk space requirements during upgrade require attention.
Upgrading to V22.0 requires approximately 150GB of free disk space, however, the final upgraded ledger size is ~50GB. The upgrade takes between 30 minutes and 4 hours on most machines, depending on the speed of the disk.
Due to these impacts, upgrading the database in a staging environment is recommended where possible. For operators who are unable to perform this direct upgrade, you may download a snapshot of an already upgraded ledger.
We are in the process of adding online upgrade support for future versions which will eliminate these upgrade disk requirements.
As a best security and node management practice, the
latest tag for Docker containers has been removed from available tags at https://hub.docker.com/r/nanocurrency/nano. Going forward the only tags available for the live network will be explicit version tags, no dynamically updated tags will be maintained. For this upgrade, the tag
V22.0 will be required.
Upcoming canary block for final votes activation¶
In order for nodes to begin issuing final votes for unconfirmed blocks, and using those votes for cementing blocks, a canary block will need to be distributed to activate the feature. To ensure enough vote weight is prepared for the consensus change, the Nano Foundation will be monitoring upgrades on the network and will distribute the canary block once at least 80% of voting weight is on V22.0+.
To stay updated on progress towards the canary block distribution, please sign up for the technical update mailing list.
Remove election difficulty sorting¶
Higher work difficulty on blocks will no longer result in increased election priority. Instead, a new election prioritization and scheduling mechanism was designed with initial changes being made in this release. With these changes the work generation is still required for transactions to be valid, but higher difficulties are no longer part of prioritization. Instead, the balance of the account and the time it was last used will be used to determine when elections are started.
For nearly all services and integrations this will have no noticeable impact on how quickly voting will begin on a published transaction. As more improvements are added in V23, addition details will be available about the future of work generation and recommendations for optimizing this in the long term.
Node count limits per subnetwork¶
The current limits of 5 nodes per IPv4 address is being expanded to include /48 IPv6 subnetwork as well. In addition, a 20 node limit is being applied to the /24 IPv4 range and /32 IPv6 range.
Node V19.0 or later required¶
Upgrades from versions below V19.0 have been removed from the code base. All nodes must be on at least V19.0 for the upgrade to V22.0 to work. Note that participation on the live network does require at least V21.0 of the node.
To help with handle specific fork situations, the final votes feature will add a second round of voting to the consensus process as follows: once initial voting weight for an unconfirmed block has reached quorum, nodes will issue final votes by setting the timestamp to the maximum integer possible for that field (
18446744073709551615). These final votes will then be required to confirm and cement a block in the ledger.
Because this is a consensus change, a network upgrade is required to activate. As noted above, this will be done using a canary block once at least 80% of voting weight on the network has been upgraded. After the canary block is distributed by the Nano Foundation, the final votes will be used for cementing going forward.
RocksDB remains experimental
Previous communications related to RocksDB being approved for production use should be ignored. The RocksDB should still be considered experimental and not recommended for production use.
Experimental ledger pruning¶
An initial, experimental version of a much requested feature is being made available in V22.0. This feature is NOT for production use. Many of the details can be found in the related pull request, but the main goal is to reduce the disk space required for the ledger by removing blocks not near the frontiers or that are pending sends. Although the final ledger size will be significantly reduced, it does require first downloading the full ledger and then pruning, to ensure integrity of the data. It also is not available for voting nodes, only non-voting nodes will allow this feature.
Election scheduler and prioritization changes¶
A new election prioritization and scheduling mechanism was designed and the initial updates for this feature are included in this release. These changes will keep work generation as a requirement for transactions to be valid, but switch the election scheduler and prioritization behaviors to use a combination of balance and time since the account was last used. With this approach nodes across the network are expected to see improved performance in clearing the backlog of elections while the network is not actively under spam attack. Future changes in V23 will be targeting improved performance while the network is under load.
Node configuration and management updates¶
- REMOVAL The
online_weight_quorumvalue, which was used in combination with online voting weight values to determine the voting weight necessary for confirming a block, has been removed as a configuration option and hardcoded to 67% for all nodes. Any existing overrides for
config-node.tomlfile can be removed.
- The default value for
config-node.tomlhas been reduced from 50,000 to 5,000. This change was to help limit extra network traffic generated by large amounts of elections as behavior of the active elections container was modified for election scheduler and prioritization needs.
- BREAKING CHANGE All RPCs with the
include_only_confirmedoption available has that option set by default and setting it explicitly to
falsewill be required to have unconfirmed blocks returned/counted in the response (such as
balanceamounts). These RPCs include:
- NEW OPTION account_balance
- Option to
include_only_confirmedblocks for the returned
pendingfields was added to
include_confirmedoption to provide extra
account_infoalso added (
confirmed_heightwas only added for consistency in naming, as
confirmation_heightalready existed and will be the same value).
- BREAKING CHANGE
block_count_typewas removed after the database upgrade that merged blocks into the state block format was completed.
- BREAKING CHANGE When both
sortingoptions are included in the RPC pending, the result will now be done over all pending blocks before the subset is returned. Previously only a portion of the pending was scanned before returning the requested count.
bootstrap_anynow allows and optional
accountfield for targeting specific account attempt
bootstrap_lazynow returns more accurate status of whether the bootstrap was
startedand whether a new lazy
- Passing values using the
--configcommand no longer require escaping of quotes
--migrate_database_lmdb_to_rocksdbdoes the necessary migration of an existing LMDB database over to RocksDB. Note that after migration the necessary configuration changes to enabled RocksDB must be done to use the new backend.
confirmationhas new optional
include_election_info_with_voteswhich will include the
weightfor each of the votes on the election.
- When a legacy bootstrap is returned from RPC
last_accountwill now be included
- NEW CLI
--debug_unconfirmed_frontiersoutputs the frontier and confirmed (cemented) frontier for any accounts which are not yet fully cemented (warning: could output a lot if used on a ledger with large amount of uncemented blocks).
nano_test_networkadded which is the basis for the new public test network for integration testing (test.nano.org) and allows customizing of various core network parameters to allow for custom test networks to be deployed from scratch.
- C++17 support is now required
- Block rollback messages in logs are no longer available by default to avoid excessive logs in certain scenarios (
node.logging.ledger_rollbackoption to enable)
- Signals available for config file reloading with initial support for
bandwidth_limit_burst_ratiooptions by calling
kill -SIGHUP [process #]
- All RPC
payment_*removed (previously deprecated in V19.0)
active_difficulydeprecated due to difficulty not longer being used for prioritization, only for checking validity of blocks
- CLI commands
--debug_mass_activityremoved (previously deprecated in V21.0)