As the Lydia v20 release approaches, we have more updates to share on Nano PoW development, details on the transition plan for the new algorithm and other useful information for our community, node operators and organizations integrating with Nano.
Algorithm details and changes
Update, Mar 6, 2020: While research continues into the viability of Nano PoW and the potential application of other algorithms, including Equihash, we have announced plans to optimize the tuning of the current algorithm for Athena V21.
Development Update: V21 PoW Difficulty Increases
Today we are announcing Proof of Work difficulty updates in the upcoming V21 release. Read our development update for…
Last week we released Nano PoW — The Details, a technical overview of the newly proposed Nano PoW algorithm. This provided a deeper look into the design and specification of the algorithm, expanding on the high-level overview provided in The Essentials article.
Nano PoW — The Details
A thorough technical look at Nano PoW, a unique authentication-free rate-limiting algorithm designed for the Nano…
Simultaneously, we opened the GitHub repository for a Nano PoW reference implementation and shared it across our community and social channels to show the progress we have made and hopefully get additional eyes on it for review. The response was great and immediately sparked conversations about what potential impacts the algorithm may have on our network and how it relates to other algorithms already available.
We want to give a special thanks to John Tromp for joining in with his valuable feedback. As the designer of Cuckoo Cycle, an existing memory-bound proof-of-work algorithm used in various cryptocurrencies, he is an expert in these types of algorithms and was able to suggest an efficient solution to the problem using no memory. This solution was implemented thanks to community member PlasmaPower and generated valuable discussion in our #nano-pow channel on Discord.
Plans for V20
After taking feedback from these Nano PoW discussions our team has made some adjustments to our plans for V20. We will not be including the algorithm in this release to allow more time for research and validation of ideas to overcome the no memory alternative solution suggested above.
Some of the avenues we are exploring are based on suggestions from John and PlasmaPower including revisiting Equihash implementations and variations, as well as reviewing further details around Cuckoo Cycle solvers. We are looking for these efforts to better shape the design of Nano PoW to ensure memory-hardness is retained while satisfying our original goals of instant verification, small proof size, and simple specification.
As we wanted to remain flexible with the release, we have built the various components related to the PoW algorithm change as independently as possible. This means we can move forward with setting the groundwork for an algorithm change in the future within V20 while minimizing schedule impacts. Below we explain these improvements in more detail.
Separating PoW from the node process
In V19.0 options were added allowing the RPC server to be moved out of process. This means the RPC server that relays commands to the node is no longer running as part of the node process. This not only helps enable more flexible and robust architectures for node operators but also increases security by separating concerns for the different components.
This same concept of component separation is being continued in V20 with some foundational work for a separate PoW server. The current PoW generation methods are built into the Nano node itself, which means if you want to generate work you can either run a node, setup the Nano work server separately or build your own solution for work generation.
Because there are extra maintenance considerations for having work generation code in the node as well as a separate implementation via the server, one of the efforts in V20 is to create a work generation server that can be pulled into the node as a submodule and launched into a separate process by the node, as well as be used separately as a standalone server. This makes it easier to maintain because the work generation code will be in a single repository, and it also provides a more consistent solution for others to use for their work generation needs.
This server is being included in the V20 release, however, it will not be enabled for work generation initially as it is dedicated to generating work using the future algorithm. Configuration settings can be updated to launch the server and it will return mock responses for those wanting to do early validation of the setup in their systems.
API for work management
Since the PoW server will now be separate from the node, communication must be facilitated between these different processes. A basic API will be available for handling this via HTTP POST calls and websockets. For integrations looking to distribute resources this provides more options for work generation architectures:
- Run a full node with the work server included
- Run a work server only and set it as a work peer in a remote node
- Run a work server only and communicate directly to it from another application
New epoch version support
Once the final algorithm design is ready, the network must transition from using the existing PoW to the new PoW. Details on this transition process are included in more detail below with part of it involving the use of epoch blocks. In V20 support for a new epoch block is being added, however, it will be designed to not cause any changes to protocol or node behavior if activated since it will be tied to the algorithm change.
In a future release, the new algorithm design will be added into the PoW server and the epoch block will be modified to allow it to trigger the switch between the existing PoW to the new PoW. Node operators and representatives are encouraged to review the upgrades and reach out with any questions or concerns about the proposed changes.
PoW transition plans
The plan for transitioning from the existing PoW algorithm to the new PoW algorithm involves a few phases, including node upgrades and a switchover based on the distribution of epoch blocks.
Phase 1: V20 Lydia release
Once the V20 release builds are ready (final date still pending), we will be notifying all node operators and services through our usual channels. As noted above this release does not include the Nano PoW algorithm but will have foundational updates to make the PoW transition easier when the algorithm is ready.
Phase 2: VXX.X release
This undetermined release will include the new PoW algorithm, a new version of state blocks required to support the work values, and other updates to allow the final phase of the transition.
Phase 3: Epoch block distribution
To finalize the transition, the network will be monitored closely for upgrades to the latest version supporting the algorithm. Once sufficient voting weight is upgraded, which is a value still to be determined, the epoch blocks will be distributed.
The above details just touch on these activities so we have included more details about the upcoming transition, along with past upgrade processes, on a new Network Upgrades page in our documentation. We will keep this updated over time with the latest details as we move through the process.
We will also continue to communicate transition details through all channels to ensure as many node operators as possible are comfortable with the progress and the plan. Not only are node upgrades and vote delegations key indicators for support for the changes we propose, but so are the discussions happening in our community. If you have any thoughts or feedback, please reach out via GitHub, Discord and Reddit as well as through email at firstname.lastname@example.org.
Where to go from here?
Thanks for reading through all of the above details. Hopefully, this explains some of the recent changes and gives you the resources to investigate this transition further. As mentioned above, additional communications will be coming out on a regular basis to keep everyone in the loop about the new PoW algorithm, V20 progress, transition plans and more — so stay tuned.
And of course we want to thank our amazing community for helping get the Nano network this far. Much of the effort made to date was only possible because of how much the community helps out. By answering each other’s questions, supporting each other's projects and keeping conversations alive around all channels, everyone involved in the ecosystem has had a hand in getting us here…and hopefully will help continue the progress going forward!