Progress Towards Achieving Commercial Grade

For the last eight years, nano has been a ground-breaking & sustainable financial network handling more than 180 million blocks. Since we began measuring value transfers about 5 years ago, over $5 billion have been processed, averaging around $3 million per day. All of this has been achieved without fees, in an eco-friendly manner, and with settlements in under a second.

To put things into perspective, active users on platforms like PayPal average about 50 transactions annually. In our current configuration, nano can accommodate 30 million such users in a fully decentralised and open manner. However, we aspire for more.

While we've largely thrived, we've also faced challenges. Two instances of denial of service (DoS) attacks caused desynchronization between nodes, leading to a degraded network state with low confirmation rates. These events highlight the importance of constant vigilance and adaptability. They also reinforce our commitment to achieving commercial grade. It's not just about scaling but ensuring that every transaction processes seamlessly, especially during peak network activity, thereby fortifying nano's resilience through continuous technical improvement.

Let's first take a look at our recent achievements and then dive deep into our roadmap, underscoring our commitment to reach commercial grade.

---

Milestones Achieved in the Past Year

As we march forward, it's essential to reflect on the strides we've made in the recent past:

• Bootstrap rewrite: We rewrote the node's bootstrapping algorithm greatly improving speed and efficiency.

• Code Refactor: We revamped our codebase, enhancing its efficiency, and ensuring agility.

• Improved Testing: We ramped up our testing processes,, both at component and system levels.

• Enhanced Debugging & Visualisations: Advanced debugging tools and visual analytics have provided invaluable insights into node behaviour..

Additionally, two major releases have propelled our network throughput, as visualised in the graph below.

 

---

Ensuring Rapid and Reliable Development

The intertwined relationship of quality and speed in software development might appear counterintuitive. However, in their book 'Accelerate', Gene Kim and his team demonstrate that there's no need to compromise between enhancing performance and achieving greater stability and quality. In fact, top performers shine in both dimensions. A primary reason for this is the efficiency gained from thorough testing procedures. Early error detection and rectification not only save invaluable development time down the road but also ensure the software remains in a deployable state at all times.

From the start, nano recognized this principle. We've consistently emphasised the importance of unit tests, ensuring each distinct component of our software performs as designed. With a suite of over 800 tests, every aspect of the system undergoes rigorous scrutiny.

Consider these unit tests analogous to inspecting every component of a car, from the engine to the brakes. Yet, just as inspecting parts doesn't negate the need for a comprehensive test drive, these unit tests can't replace holistic system checks.

Over the last year, we've introduced automated integration tests which simulate a full-fledged network and validate that every change leads to transactions being confirmed within the expected timeframe. By automating this process, we ensure that any systemic issues are identified and addressed at the earliest opportunity.

 

---

Our Upcoming Challenges and Commitments towards commercial grade

1. Sustained Performance After Network Saturation

One of our primary benchmarks for reaching commercial grade is performance maintenance post-saturation. The idea is to maintain a high confirmation rate independent of external factors and usage.

Our local test networks highlighted a reduced confirmation rate with large unconfirmed transaction backlogs. This challenge has been addressed, with the solution making its debut in the next major V26 release.

2. Bounded Disk Storage

In addition to maintaining performance under network saturation, nodes need to maintain a bounded amount of storage growth over time. Currently, unconfirmed blocks consume disk resources due to the way blocks are processed.

Bounding disk storage requires both maintaining performance under network saturation and also a rewrite of how blocks are handled in the block processing pipeline.

Work to redesign the block processing pipeline has already commenced and the ability for nodes to set a maximum number of confirmation per second will be added to complement the existing node bandwidth limiter.

3. Spam/DoS Resistance

Nano has a unique transaction prioritisation system based on the last transaction time of an account and its balance. Through strategic categorization into specific buckets—determined by the larger of the two: account balance or transaction amount—we proactively prevent spam transactions from congesting the network. 

This method ensures genuine transactions are prioritised, especially from less frequently used accounts, allowing them to proceed without interference from potential spam.

In our pursuit of increasing DoS resistance, we're drafting a peer rating system. This system will identify and manage peers that display irregular behaviours, such as sending improperly signed messages or excessively flooding the network. While the specifics are still under consideration, this measure aims to maintain network health by potentially limiting or temporarily isolating such non-compliant peers.

---

Beyond Commercial Grade: Future Innovations and Developments

Reaching commercial grade marks a significant milestone in a continuum of growth and improvement. Here's a glimpse into some of the avenues we're exploring post-commercial grade:

1. Long term storage

Over time the storage requirements of the nano ledger grows as users perform transactions. Due to the nature of how blockchains work, historical transactions need to be considered in perpetuity which constitutes a data storage concern for nodes that connect to the network.

Mitigating the data storage issue is the fact that historical transactions almost never need to be referenced and when they do, they don't need to be referenced as quickly as recent transactions. With this in mind it is possible for nodes to archive historical transactions in a common place, for instance a p2p distributed hash table network, so the historical data doesn't need to be duplicated and stored on every node.

2. Network topology improvement

The primary limiting factor for network scaling is bandwidth requirements. Bandwidth requirements scale as the product of transaction rate and network decentralisation. The majority of bandwidth goes to broadcasting votes to nodes on the network.

The network currently uses a simplistic broadcasting algorithm which results in a noticeable amount of repeated data. The ideal broadcasting would ensure every node on the network reliably receives one single copy of broadcasted data.

This change would involve a redesign using techniques similar to multicast or other broadcast/flooding algorithms used in other p2p systems.

---

In summary, our journey towards achieving commercial grade is filled with relentless dedication to create the best version of digital cash. As we progress, we invite all the eager watchers to become an integral part of this growth story. Your insights and involvement will make us stronger. Together, let's forge the future!