Nano Development Update — March 2021
We’ve had an interesting end to 2020 and transition into 2021 with many changes across our ecosystem. Although we’ve been quiet about development activity recently, we have some great updates to share today about our development team and the next version of the Nano node software.
Team updates
There are various team updates underway at the Nano Foundation which will give some rest and provide new energy soon as we get deeper into some exciting updates this year. Our Project Manager, Zach Hyatt, is taking some time off over the coming months. His availability will be reduced through March and he will be stepping away from day-to-day operations from April until summer, when we look forward to his return. You may not see him in our channels as much during this time, but he will be here in spirit.
We are also excited about the many interviews we have been conducting for our open Lead Software Engineer position. Hiring new engineers on the team is a priority so we encourage everyone to keep an eye out for future open positions and send talent our way via the jobs@nano.org email. We are looking forward to sharing more updates in this area soon.
We also enjoy seeing contributions to the node software, so even if you aren’t looking for a position at the Nano Foundation, join our core developers by checking out the developer start pack documentation and send us a pull request or two.
V22 development
While various team changes are underway, we continue making great progress on the development of V22 of the Nano node. Over the past months, there have been shifts in the priorities for the release, which are now reflected in the Roadmap and highlighted below.
What remains the same
Some of the most anticipated features in V22 will be available upon upgrading, including RocksDB as a production-ready database option and experimental ledger pruning. With over 180 Pull Requests already committed, there are plenty of other bug fixes, optimizations and improvements to be included as well.
More election, voting and fork resource adjustments
Beyond some of the updates previously communicated, we have identified opportunities for improvement in areas around election management, voting activity, fork resource usage and elsewhere. A big thanks to our community for helping test on the beta network to find some of these options.
Some interesting changes worth highlighting include:
Timestamps in votes
This change from incrementing sequence numbers to timestamps offers a useful metric for evaluating the potential age of votes and is required for historical consensus evaluation when non-PR vote storage is available in later releases.
Vote spacing
The fork resolution process requires nodes to monitor voting weight for all competing blocks for an election. If the block they voted for is on the losing side of the voting weight, then a new vote for the winning block is issued without delay. Under some network conditions, this can cause some rapid vote generation and extra resource consumption on nodes. To better throttle this behavior, nodes will have a minimum spacing between votes. This will slow down the fork resolution process for these elections but conserve resources so that more elections where there aren’t forks being produced can be cleared out during heavy traffic times.
Final votes
Despite previously de-prioritizing the development of a “Dual-phase voting” feature, which involves the issuing of a final vote for confirmation, a couple of recent activities brought this idea back into play. The first is recent escalations when handling certain types of forks and the approach of the final vote is aiming to mitigate that.
The concept is fairly simple: allow votes with the maximum allowed timestamp to be considered as “final” and only base confirmation decisions on those votes. The way it works is nodes will start the election on new blocks and issue their initial vote. The election will be monitored and their vote will be flipped if the winning block changes (with delays per the vote spacing feature above). This process is basically how elections are done today.
The main change is that once quorum is reached on the winning block, instead of immediately cementing with that confirmation, a final vote is first issued. Only these final votes will be used to reach quorum on the confirmation and cementing process, where confirmation height is set on the account, is completed and no further changes can be done at that height on the account.
In the future, it is possible these final votes can be used for historical consensus referencing, which would allow nodes other than Representatives to serve up historical votes that can be used to confirm blocks. This would help free up resource usage on Representatives by offloading these duties to other nodes and requires vote storage to function. In order for the votes themselves to be trustworthy, they must represent the final decision made by a Representative for an election, and thus this final votes feature aims to provide that.
A big thanks to PlasmaPower for pushing this idea forward and coming up with the initial patch that was iterated on with the help of testing from Srayman. This update will be included in the V22.0DB11 soon to be build available on the beta network and will be activated using a canary block once enough nodes on the network have upgraded. Come check it out in testing on the beta network.
New Distributed Consensus Algorithm
We are constantly looking to improve the protocol with one of these aspects being that I have been designing a unique & novel, low-latency, low-resource distributed consensus algorithm specifically designed for large-scale systems such as nano.
I’ve designed this algorithm as a traditional standalone software library that can be integrated into specific applications rather than as a SAAS platform which is the direction most of the cryptocurrency-related consensus research has focused. Jump over to the Nano forum to read the draft paper and join the discussion as this will be the primary focus of V23.
Shifting out of state block version 2
Upgrading to a new state block design is a major update and requires epoch block distribution to take effect. Because of these impacts, all options need to be weighed and prepared before committing. Since starting the discussion about a new state block design last summer, it has become clear that some open questions remain about what to include in the block and so we believe it is in the network’s best interest to push this change out to V23+ to ensure it is done properly.
Release plans
We’ve been working towards the release of V22 for some months now and are excited to be getting close to a Release Candidate in the coming weeks. To stay on top of the latest developments sign up for the technical updates newsletter.
Part of the upgrade to V22 will involve a database migration and similar to previous migrations, this process can result in downtime of minutes or hours depending on the hardware specifications of the system. Those who are looking to prepare ahead of time are encouraged to review the Ledger Management documentation including the Updating the node portion, which provides details on how best to avoid impacts. Further details will be provided around the time of release.
Equihash research
Since late 2019 we have been searching for alternatives to the current PoW algorithm and focused efforts on evaluating a novel Equihash configuration. Thankfully we were able to work with the authors of the original Equihash paper, Alex Biryukov and Dmitry Khovratovich, to get some answers to our questions.
The details of their research can be found in the final Equihash-Nano report and indicates the algorithm may be a good option to consider for implementation. Check out the recent updates on the Equihash as a new PoW algorithm forum topic and let us know what you think about these potential future changes. We are also open to other ideas around PoW solutions, or even non-PoW approaches such as the Time-as-a-currency idea on our forum.
Thank you to our community and all the supporters of the Nano ecosystem. We are looking forward to getting the next node release out on the network and appreciate all your help along the way!
