V26: Tremissis is LIVE!
Announcing the release of Nano V26 Tremissis, an upgrade that significantly improves network efficiency and resiliency, particularly during adverse network conditions like heavy spam. V26 also includes server-side support for several multi-phase improvements that will be more fully enabled in V27.
For both V26 & V27, these changes ultimately mean less network overhead, higher TPS, faster bootstrapping, improved stability & recovery during saturation or spam, & increased overall efficiency.
What's in V26?
So, what changed with V26? And what do we expect to see? Let's dive in!
Vote Hinting Improvements
One of the biggest features included in V26 is the vote hinting rework. To confirm transactions, Nano representatives start elections based on transaction priority, but during periods of heavy network traffic, there can be a significant increase in timestamp differences between nodes.
This desyncs voting & drastically reduces confirmation speed, so vote hinting was implemented to help keep the network in sync. With this feature, a percentage of election slots are reserved for hinted elections, meaning that nodes start elections for transactions with a high vote weight, regardless of individual node priority. This allows the network to progress forward on confirmations, keeping the network in sync.
V26 drastically improves how this vote hinting process works, especially by improving how missing block dependencies are handled. In some tests, these bug fixes & improvements completely eliminated election churn & timeouts.
Here is a before & after comparison of a heavily desynchronized local development environment in V25 compared to V26 (~2M transaction backlog):
Screenshot by Piotr Wójcik
V25 beta network recovery test: ~1.5 hours for 500k blocks:
Screenshot by Ricki
V26 beta network recovery test: <1.1 hours for 1M blocks:
Screenshot by Ricki
For more details:
Improved bootstrapping performance for some slower nodes
In the hinted election scheduler, some slow nodes would excessively queue background tasks related to bootstrapping. Additionally, previous behavior in the ascending bootstrapper allowed blocks to queue until the block processor was half full (~30k blocks), which didn't work well on low-performance nodes (where waiting blocks would be requested and queued multiple times). These issues were improved by fixing a hinting scheduler bug, cleaning up the vote cache, & limiting the maximum number of queued blocks.
For more details:
Server-side support for up to 255 votes per message
V26 includes server-side support for a feature that will enable nodes to vote for up to 255 transactions in a single message (in V27). Early beta tests showed a ~25% increase in performance after the beta network was fully updated to support 255 votes per message (~950 CPS saturation to ~1200 CPS saturation).
Early tests comparing 255 votes per message vs V25:
Test results by gr0vity, shared by Piotr Wójcik
For more details:
Server-side support for frontier scanning
V26 includes the server-side support for a feature that will enable the bulk scanning of frontiers to help speed up bootstrapping (in V27). Instead of sampling one account at a time, we'll be able to sample ~1000 accounts at a time, which is particularly helpful during the later stages of bootstrapping, where relatively few accounts are out of sync. Once fully implemented (V27), this will enable the complete removal of the legacy bootstrapper.
For more details:
Miscellaneous cleanup items
As usual, V26 also includes a variety of other bug fixes, unused code removals, submodule updates, & readability improvements. Besides making Nano more efficient & stable, these changes help with code maintainability & make it easier for new developers to contribute to Nano development.
For more details:
Minor updates with V26.1
V26.1 was created to include a few minor changes that improve performance & stability in some scenarios. Specifically, increasing the default block processing timeout from 15 to 300 seconds, limiting the rate at which nodes peer with other nodes, and processing connection attempts in a round-robin way in order to load-balance connection attempts. These changes build on the features included in V26.0, improving overall network efficiency & resiliency.
Representatives have already been upgrading to V26.1 over the last few weeks in response to the slowness of V25.1 following an increased load on the network.
The V26.1 patch is the current recommended release for production.
For more details on the minor updates:
What to expect in V27?
The full plan for V27 has not yet been finalized, but here are a few features currently being evaluated for inclusion:
-
Client-side support for frontier scanning in the ascended bootstrapper
- Efficient, configurable logging
-
Client-side support for up to 255 votes per message (vs 12)
-
Initial rewrites for the Bounded Block Backlog functionality that will improve network QoS.
If you would like to contribute, please check out our GitHub, or the core development documentation page. A big thank you to Patrick Luberus for the write up and analysis.
Nano Foundation does not endorse or approve products and/or services used or developed by third parties. Any links to third party software or sites are for informational purposes only. Nano Foundation bears no responsibility for the operability, accuracy, legality or content of third party products and/or services. Any questions regarding third party material should be directed to that party.