V28 Electrum: The Start of Commercial Grade

Following ten years of innovation and over 200 million processed blocks, the Nano network stands at a pivotal moment with the release of version 28 (V28), named Electrum. This release marks the beginning of Nano's transition to commercial grade - a standard of performance, reliability, and resilience. 

Understanding the Path to Commercial Grade

Commercial grade represents a comprehensive set of capabilities that will enable Nano to serve as a reliable, scalable financial network capable of handling significant transaction volumes while maintaining consistent performance. The key requirements include:

• Sustained performance during and after network saturation
• Bounded disk storage growth
• Robust spam and DoS resistance
• Reliable transaction processing regardless of network conditions

With the addition of the Bounded Block Backlog & Traffic Shaping in V28, Nano will finally achieve most of these core commercial grade requirements, although continued development and optimisation beyond this release is still planned to achieve full commercial grade status.

Electrum was a naturally occurring alloy of gold and silver used in the ancient world, it typically contained about 75% gold and 25% silver, making it a perfect metaphor for a version that's transitioning from Denarius (silver) towards Aureus (gold). This composition nicely symbolises a version that's mostly ready for the gold standard of commercial grade but still has some elements to refine.

What's in V28?

Bounded Block Backlog Implementation

Piotr’s Bounded Block Backlog (BBB) system represents a fundamental shift in how Nano handles network load and transaction processing. Unlike previous versions where unconfirmed blocks could accumulate indefinitely, BBB implements strict bounds on unconfirmed transaction storage and processing, providing several benefits:

• Controlled Resource Usage - Maintains a fixed maximum difference (currently 100,000) between blocks that are checked (initial validation) vs cemented (final confirmation)
• Predictable Performance - Ensures consistent confirmation rates even during high network load
• Enhanced Spam Resistance - Prevents resource exhaustion attacks by limiting unconfirmed block accumulation
• Optimised Storage - Reduces disk usage by properly managing unconfirmed block storage

Early testing demonstrates the system's effectiveness:

• Stable bootstrap performance without major stalls
• Consistent block processing under load
• Improved recovery from network saturation events

Traffic Shaping Implementation

Traffic shaping represents the second half of Nano's comprehensive network flow control system, complementing the fair queuing implemented in V27. This sophisticated system manages outbound network traffic, ensuring:

• Balanced Bandwidth Allocation - Equal distribution of network resources among peers
• Congestion Prevention - Proactive management of network traffic to prevent bottlenecks
• Quality of Service - Maintained performance even during peak usage
• Resource Optimisation - Efficient use of available bandwidth across the network
• Traffic Balancing by Type - Allows tuning of outbound network usage across different node functions for more optimal network usage (e.g. bootstrapping versus live voting)

The combination of fair queuing and traffic shaping creates a complete flow control system that handles both incoming and outgoing traffic efficiently, establishing a necessary foundation for commercial grade capabilities.

RocksDB Optimisations

V28 includes a range of improvements to the database layer:

• Enhanced Lock Management - Resolved premature lock release issues that could impact performance
• Improved Thread Handling - Better coordination of database operations across threads
• Optimised Memory Usage - More efficient memory allocation and management
• Enhanced Performance Under Load - Better handling of high-volume database operations
• RocksDB Modernization - Nano's RocksDB implementation has been updated to V9.7.2, and the default configuration settings have been updated to match current best practices. This results in improved stability & performance for nodes using the RocksDB database backend. Big thanks to RickiNano for his contributions to this effort!

In V28, LMDB continues to serve as the default and production-recommended database backend for the Nano node. While significant optimisations have been focused on RocksDB, both database backends remain fully supported, with all essential functionality in V28 working seamlessly across both systems. The node maintains its full functionality and stability with LMDB, ensuring current operators can continue their operations without disruption.

The strategic focus on RocksDB optimizations reflects the development team's forward-looking approach to Nano's scaling needs. RocksDB's architecture provides advantages that better align with Nano's future requirements, particularly evident in the performance improvements seen with new features like bulk frontier scanning. 

Vote Processing Enhancements

V28 introduces a range of changes to how votes are handled within the network, addressing both the generation and processing of votes to improve overall efficiency.

Vote Generator Improvements

The vote generation system has been completely redesigned to be more resource-efficient. In previous versions, vote generation could become a significant CPU burden, particularly during high-load periods. The new system introduces several optimisations:

• Improved Intelligent Vote Bundling - Instead of generating individual votes for each block, the system intelligently bundles votes for multiple blocks together, significantly reducing CPU overhead with optimisations of this system taking place in this release
• Optimised Timing Control - New timing mechanisms ensure votes are distributed more evenly across the network, preventing vote flooding scenarios
• Resource-Aware Processing - The generator now adapts its behavior based on system resources, preventing CPU spikes during heavy voting periods
• Enhanced Vote Prioritisation - Better handling of priority votes ensures confirmations aren't delayed during high-load scenarios

Vote Filter Implementation

One of V28's most impactful features is the new vote filtering system. Previous versions processed all incoming votes, leading to significant redundancy and resource usage. The new filter implements sophisticated deduplication and relevancy checks:

• Intelligent Vote Deduplication - Eliminates redundant votes for already-confirmed blocks
• Vote Relevancy Checking - Only processes votes that are necessary for achieving consensus
• Bandwidth Optimisation - The 60% reduction in processed votes directly translates to lower bandwidth requirements for nodes, lower latency and improved responsiveness
• Memory Usage Improvements - Reduced vote storage requirements through better filtering
• Network Load Reduction - Less vote traffic means more network capacity for transaction processing

Bootstrap and Database Optimisations

Bulk Frontier Scanning

The ascending bootstrapper's new bulk frontier scanning capability represents a major improvement in how nodes synchronize with the network:

• Parallel Account Processing - Instead of processing one account at a time, nodes can now scan up to 1,000 accounts simultaneously
• Efficient State Retrieval - Optimised database queries reduce the I/O overhead during bootstrapping
• Smart Caching - Implementation of intelligent caching mechanisms for frequently accessed frontier data
• Adaptive Processing - The system adjusts its scanning rate based on node resources and network conditions
• RocksDB Optimisation - Particular attention was paid to optimising bulk operations for RocksDB, resulting in significantly faster synchronization times

Legacy Bootstrapper Retirement

The complete removal of the legacy bootstrapper marks a significant milestone:

• Simplified codebase and improved maintainability
• Streamlined networking operations
• More efficient resource utilisation
• Enhanced foundation for future improvements

Legacy Code Removal

The retirement of the legacy bootstrapper is more than just code removal - it represents a significant architectural improvement:

• Architectural Cleanup - Removal of deprecated synchronization methods and associated complexity
• Memory Usage Optimisation - Elimination of redundant data structures and caching mechanisms
• Network Protocol Simplification - Streamlined bootstrap protocol without backward compatibility overhead
• Improved Error Handling - More consistent and predictable behavior during network synchronization
• Foundation for Future Improvements - Cleaner codebase enables faster implementation of future optimisations

These improvements create a more efficient and resilient network. For example, the vote filter's reduction in processed votes complements the traffic shaping improvements, while bulk frontier scanning improves node synchronisation speed. The removal of the legacy bootstrapper both simplifies the codebase and allows for more aggressive optimisation of the remaining bootstrap code.

Recent beta testing conducted by Bob has demonstrated impressive performance of V28's bounded backlog system under significant network load. In a controlled test environment, the network successfully handled a sudden influx of 200,000 blocks while maintaining remarkable stability and performance. 

During this heavy spam test, legitimate transactions continued to achieve confirmation times under 1.5 seconds, highlighting the effectiveness of the new prioritization mechanisms. The backlog processing showed sustained throughput of approximately 300 transactions per second (TPS), while the bounded backlog system successfully maintained its target cap of around 100,000 blocks.

Looking Ahead: V29 and Beyond

The path to full commercial grade status continues with future developments:

Enhanced Peer Management

Future versions will introduce:

• Sophisticated peer scoring systems
• Improved representative identification methods
• Enhanced network topology optimisation

Network Scaling Improvements

Ongoing development focuses on:

• Vote traffic optimisation
• Multi-node representative crawl enhancements
• Advanced network infrastructure adaptations

Continued Optimisation

Future releases will focus on:

• Fine-tuning bounded backlog parameters
• Optimising traffic shaping algorithms
• Enhancing overall network efficiency
• Further spam resistance improvements

The Future of Automating Receive Blocks

Receive blocks are an integral part of the Block-Lattice structure; while providing crucial benefits through fixed transaction sizes and efficient bookkeeping, however the current implementation also presents integration challenges that we aim to address. 

Looking ahead, we envision a streamlined approach that automates receive block processing in a way that does not require end-user signing outside of their normal transaction workflow. 

Reducing PoW on Blocks

Proof of Work, once a cornerstone in Nano’s spam prevention, has seen its role evolve with the implementation of novel systems such as Bounded Backlog, fair queueing and the bucketing system and with such advancements, the workload required by the PoW mechanism for anti-spam measures has been drastically reduced.

The motivation to heavily reduce the PoW difficulty is to ease the burden for integrations when generating transactions. Ideally, the PoW computation can be imperceivable to users while still being effective at prevention of bulk DoS traffic.

If you would like to contribute to these ongoing developments, please visit our GitHub or check out the core development documentation page.