Kaspa on Rust: Evolving Testnet 11
Breaking New Ground in PoW Efficiency with Rust
Pushing Boundaries… Again!
On the evening of January 7th, at 8 PM UTC, another pivotal chapter in the Kaspa saga will be written in code and history with the second unveiling of Testnet 11 (TN 11). This public release is the second expedition into the new Rust codebase that brings the promise of the impossible 10 blocks per second (10 BPS) on a proof-of-work (PoW) network. The digital experiment provides an arena where developers and enthusiasts will come together to push the envelope, exploring the dynamics of the PHANTOM GHOSTDAG protocol live on the Rust programming language.
Testnet 11 is far more than a proving ground; it’s a digital recreation of the real world. Focused on simulating and stress-testing a miniature version of an entire ecosystem, a world’s worth of transactions, all anxious to settle instantly to buy their favorite snacks. Its evolution on fast-forward, where the protocol endures rigorous trials, loads of simulated throughput, real-world mining and use, all while ensuring efficiency and security against any real-world scenario.
Rusty Kaspa
Rewriting the Kaspa programming language from Go to Rust is an essential development to enhance performance and manage the complexities of the BlockDAG. This transition enables the groundbreaking achievement of 10 BPS, which allows for greater scalability and throughput. By increasing the BPS, the potential transactions per second go upwards to 3,000 TPS, as demonstrated in the highly successful first public release of TN11. The Rust programming language offers advantages such as higher efficiency and improved performance, memory safety, interoperability, error handling, and a growing crypto ecosystem and developer community.
Testnet 11 Updates
Since the first public Testnet 11 captivated the crypto world, several enhancements have been implemented to optimize network efficiency and performance. Improving high BPS Peer-to-Peer (P2P) communication, focusing on fine-tuning and orphan revalidation, is crucial for seamless network functionality under high transaction volumes.
Storage efficiency has also advanced with updates addressing the issue of quadratic writes in high BPS contexts, refining the network’s data processing and storage capabilities. These updates, along with smarter caching through dynamic data tracking and enhancements like parallel processing for block submissions, signify a considerable leap forward for Kaspa, a display of the developers’ ingenuity and insights gathered from the initial experiment. Refer to the Release Notes at the bottom of this article for a comprehensive overview of the updates.
Participating in Testnet 11
Participating in Testnet 11 is straightforward, primarily focusing on software requirements. The essential software needed is Rusty Kaspa, which acts as a portal, seamlessly connecting your system to the network. This enables synchronization with other nodes on TN 11. You have the option to run the node as it is, which is a straightforward way to participate. However, Rusty Kaspa also opens the door to additional testing features if you want to explore further.
CPU mining is the exclusive method for mining in Testnet 11, and it’s a crucial aspect of the process. By participating in CPU mining, you contribute to the TN 11’s computational strength. The advantage here is the simplicity and accessibility: you don’t need any specialized mining software or hardware to get involved. TN 11 comes equipped with its own CPU miner, making it easy for anyone to participate in this capacity. Although transaction simulation using the Rothschild tool is optional, if you decide to mine on TN 11, it’s vital to use CPU mining. This method is the designated approach for mining in the network. This simplifies and democratizes participation, enabling a broader range of users to contribute effectively and interact with the network’s features.
For hardware, a setup with at least 16GB of RAM, an 8-core CPU, and a 128GB SSD drive is recommended to handle the demands of the TN 11 environment efficiently.
Testnet 11 Instructions
The Kaspa Discord #testnet channel is your go-to for troubleshooting and discussion. At the same time, #rust-rewrite offers a greater understanding of Rusty Kaspa development and updates.
Redefining the Proof-of-Work Consensus
Testnet 11’s performance is key to shaping Kaspa’s future, especially the shift to 10 BPS speeds on the mainnet. The data from these tests are necessary to tackle any needed optimizations and prepare for the mainnet to operate on Rustlang.
For a deep dive into participating and understanding the Rust rewrite, check out the Rusty Kaspa GitHubpage. Remember, TN 11 is an experimental zone — expect some instability as part of the process.
The release of Testnet 11 marks a significant stride in cryptocurrency innovation, offering a unique platform for testing and fortifying the developmental foundation of the Kaspa PHANTOM GHOSTDAG protocol. It’s a critical step in the quest to push the boundaries and achieve the ultimate goal of 100 BPS.
Tip: It’s important to remember that Testnet 11 is a testing environment. It may face instability and occasional downtime due to experimentation processes. Nothing to worry about, and it’s anticipated.
Release Notes
Testnet 11 Updates
- Fine-tuning — https://github.com/kaspanet/rusty-kaspa/pull/356
- Orphan revalidation — https://github.com/kaspanet/rusty-kaspa/pull/359
- Perfects the P2P at high BPS. Also fixes the long-standing IBD loop.
Improvements to storage efficiency:
- Reachability refactor: https://github.com/kaspanet/rusty-kaspa/pull/347
- Block child relation refactor: https://github.com/kaspanet/rusty-kaspa/pull/325
- These PRs together eliminate quadratic writes in higher BPS to their respective storages, allowing the node to store block reachability and child relation data efficiently.
- https://github.com/kaspanet/rusty-kaspa/pull/351
- Caches for dynamic data now track that size and adjust accordingly.
- This should prevent Out-of-Memory issues — the caches are limited to what is needed for the node to operate smoothly.
- https://github.com/kaspanet/rusty-kaspa/pull/357 — Parallel submit block processing — Submitting blocks can fill the message queue in higher bps, leading to serialization of processing (defeating the purpose of higher bps). This fixes that.
- https://github.com/kaspanet/rusty-kaspa/pull/320 — Various initial fixes from issues found in the internal TN11 experiment
- https://github.com/kaspanet/rusty-kaspa/pull/317 — Clear block template only when it’s expired.
- https://github.com/kaspanet/rusty-kaspa/pull/311 — Add request and response ID to every p2p message and route messages accordingly.
- https://github.com/kaspanet/rusty-kaspa/pull/356/files — Fine-tuning parameters.
Other non-TN11 Rusty Kaspa Update
Improvement to node initialization and overall health:
- https://github.com/kaspanet/rusty-kaspa/pull/333
- https://github.com/kaspanet/rusty-kaspa/pull/345
- These initialize the FD limits so that the node will have the resources it needs to run.
- https://github.com/kaspanet/rusty-kaspa/pull/360
- This is the solid foundation on which the new rust-based KNG wallet is based.
Improvements to node reachability via UPnP
- https://github.com/kaspanet/rusty-kaspa/pull/300
- https://github.com/kaspanet/rusty-kaspa/pull/288
- These changes introduce UPnP, which allows more nodes to become publicly connectable. The more public nodes there are in the network, the better the interconnectivity of the network becomes.
Covered by the release notes in https://github.com/kaspanet/rusty-kaspa/releases/tag/v0.13.0
KASPA | KASPA WIKI | MEDIUM | TELETYPE | DISCORD | TELEGRAM
TWITTER | REDDIT | GITHUB | EXPLORER | Bubblegum Lightning