V19 Solidus — Feature Analysis
With the Solidus release marching towards us at a steady pace, we could wait no longer to present some of the exciting new additions to the Nano node software. Our developers, aided by our army of community developers, have been focused on delivering yet another set of features to make our network stronger, easier to integrate and more resistant to bad actors.
Our Dolphin V18 release helped streamline the network with fast and consistent transaction times, and now Solidus will consolidate the network creating an even more robust protocol.
Although the sum of the new features provides more stability and accessibility for the network than they offer individually, to understand their strength we must look at them one-by-one, starting with confirmation height.
Solidus is taking Nano to new heights
One of the most anticipated features of Solidus is Confirmation Height. This update adds a new field on all accounts that will record the height of the last confirmed block (which is the count of the number of blocks to that point). This count is recorded locally on the node rather than being shared across the entire network. This enables block cementing — once a block is confirmed across the network, it is prevented from being rolled back locally based on this field.
This process provides some important benefits including lower resource usage and easier integration methods. The details of this addition were extensively covered in our Confirmation Height article a few weeks ago. We encourage anyone interested in learning more to click the link below!
Exploring how high this new feature in V19 Solidus will take usmedium.com
Setting siege to spam with dynamic proof-of-work
With any fee-less network there is potential for spam abuse. Nano was designed to combat spam by requiring a small Proof-of-Work (PoW) attached to each block published. To date, the minimum threshold for difficulty on the PoW was static and all transactions have been treated the same. With Solidus, this process becomes more dynamic.
Through a combination of features that a) help the node track the average PoW levels on the network, b) regenerate work for published blocks that aren’t being confirmed quickly enough, and c) prioritize processing based on the PoW difficulty, the cost of sustained spam on the Nano network that attempts to slow down fast confirmation times is getting much higher.
For services that do not use the Nano node for work generation but have chosen to perform this externally through their own implementations, updates will be required to ensure that work values are in line with the network average. Look for more info about impacts to external systems in our upcoming article which will break down the mechanics of Dynamic PoW in more detail.
Getting precise with TCP
Until today, all versions of the Nano node have communicated live network traffic over the User Datagram Protocol (UDP). There are some advantages to using UDP as it doesn’t require confirmation of receipt, but with it come drawbacks like lost traffic resulting in wasted bandwidth.
With Solidus, the node is being converted to participate on the live network using the Transmission Control Protocol (TCP) which will help reduce lost packets and is also more widely supported across various types of networks. This will allow for easier integrations, lower resource usage, and open up more efficient peering across the network. The same recommended port configurations used by the TCP bootstrapping network apply to this update. This allows for a smooth transition when upgrading.
The gold standard prefix: nano_
When addresses are returned by the Nano node, they include a prefix of “xrb_”, which is related to the previous RaiBlocks name we have been transitioning away from. With Solidus we charge forward to a more brand-aligned “nano_” prefix, and these updated addresses will be emitted going forward.
We recommend all services test and verify they properly support “nano_” prefixed addresses for all their integration points before upgrading to V19. Any questions about these impacts should be directed to the Nano Foundation.
PLEASE NOTE: These changes have no impact on the security or availability of the funds controlled by your private seed. Even if a service you use has not adjusted to the “nano_” address change, you will be able to use other services with your seed or use an “xrb_” address instead.
This is based on #1521 from @rkeene see that for more info.github.com
RPC achieves process independence
The Nano node is comprised of various components that enable participation in consensus, sending of funds, and more. Initially, each of these pieces were created and connected in a central application. Moving forward, to help provide better options for managing how they work together, many are being split up into their own areas.
The Remote Procedure Call (RPC) server that helps handle communications to the node is getting this treatment with an optional move to its own process. By default, it will continue to run within the main node process, but a configuration change allows it to operate outside in a new dedicated process. This allows for greater control of the service and reduced attack surface of the node as their concerns are now separated.
Enjoy your (optional) independence, RPC.
This solves #1827 The RPC server has now been moved to a new executable. If rpc_enable is set to true a new rpc_path…github.com
Solidus to make integrations even easier
For exchanges and services, the Nano node has always provided good options for integration, and Solidus will add to that with it even more helpful updates, increasing the ease at which the Nano ecosystem can expand.
Minting that block_info
As a widely used RPC endpoint, the block_info call accepts a block hash and returns tons of relevant data for that block to be used in various ways. Some new additions to the returned data are key to simplifying integrations — starting with the confirmation status. As part of the Confirmation Height feature, finding out if a particular block has been confirmed by the network will be as simple as calling block_info and reading the true or false value of the “confirmed” key. It’s almost too easy.
There are also situations where determining the subtype of a state block is tricky because it is not explicitly included in the block itself. Instead, it must be determined by the values in other fields. To help streamline this identification, another new key called “subtype” was added in the block_info call so it is explicit and easily found.
Finally, you won’t always want to get these new details for just a single block, so both confirmed and subtype details are available for multiple blocks via the blocks_info call as well. Time for a block party!
Websocket to me — efficient communication with the node
Getting notifications for blocks being confirmed on the node is important when building any second-layer solution. Current implementations use a mechanism which triggers callbacks to a configured URL via http. This requires a new connection to be opened with each callback and requires callbacks for every confirmed block, both of which are inefficient behaviors.
In Solidus, support for a new callback mechanism through websockets is included. This allows a single connection to be opened and a subscribe action to be called, which allows the notifications across that one particular connection. Not only is this a more efficient way to receive these details, but it also establishes the framework for future updates to allow notifications of additional events and even filtering options.
Adds support for notifications via Websockets. This offers a more efficient callback mechanism for block confirmations…github.com
Nano grows in strength
These highlighted features are some of the more impactful and important changes Solidus is bringing under its banner. V19 is comprised of over 100 pull requests, so rest assured there are many other improvements coming to the node. To see the full list and follow along as we get closer to release, check out the V19 GitHub Release tracker.