And as if a new PoW algorithm wasn’t enough for this release, we also have other significant updates coming with Lydia:

Config management made easy

Configuration management is something we have been eager to improve for a while. Existing .json config files are challenging to maintain and don’t allow commenting. Additionally, both the node and user have been writing to the same file, which can cause confusion and overwriting of values over time.

With Lydia, we are moving to a .toml format for better legibility and to allow commenting. We will also have defaults in the node so users can override only the values they wish to change. This setup will make things easier to read, maintain, and understand going forward.

Beta net brings better optimizations

The extensive beta testing performed on the Solidus release over the last 2 months revealed various areas for improvement both in the node and in our testing and release processes. Various team members helped implement some fundamental advances in the beta network setup and have been using those to drive even more understanding of network behaviors.

We would like to give a huge thanks to our fantastic community of beta-testers for all their help!

Lydia is taking the lessons learned on beta and optimizing various node operations, including block propagation, vote caching and rebroadcasting, bootstrap behavior, and disk I/O operations. This version continues the trend of optimizing and streamlining the node for lower, more efficient resource usage across the board.

Dynamic PoW from outside the wallet

When Dynamic Proof-of-Work and Prioritization was implemented, it was done so within the architecture of the node wallet, resulting in the node only requesting rework when using wallet-based RPC calls. As the node wallet is only for testing and development use, this left external, production integrations on their own for implementing the tracking and rework requests to give their users higher Proof-of-Work during heavy traffic times.

With V20.0, it will be possible to signal to the node that it should watch a published block for any delays that would warrant rework, and then handle those work requests. This will happen by default with process RPC calls (but can be disabled), so anyone gets to enjoy these benefits. Go Lydia!

Experimental support for RocksDB

P lease note: The current implementation of RockDB is not recommended for production systems. It is currently experimental and suggested for testing and development use only.

Since the beginning, the Nano node has used the Lightning Memory-Mapped Database (LMDB) to manage the ledger. Despite many useful advantages of LMDB, it remains aggressive in the amount of disk I/O operations it executes. Exploration of other alternative databases highlighted RocksDB as a good candidate in providing better performance for disk I/O, so we’ve included an optional implementation for experimentation.

Early tests indicate disk I/O will likely be lower with default configurations, and additional tuning should allow us to optimize further as we work to tweak and validate RocksDB as a potential option for use in future production nodes.