Kaspa’s Crescendo Hard Fork Debuts with a 10BPS
Kaspa’s much-awaited Rust rewrite is complete, and the team is ready to launch its hard fork with improved blocks per second, 10BPS.
Quick Summary
The much-awaited Rust rewrite is done, and the first stable Rusty Kaspa (RK) node is released for Kaspa’s Peer-to-Peer (P2P) network and Kaspa mining community. This is a substantial milestone for the Kaspa network, as it is now upgraded with a new, enhanced, and optimized engine that businesses and developers can leverage to their advantage.
However, that is not the end of the story. The dedicated open-source development team is now creating a hard fork named Crescendo with an enhanced block rate of the network from 1 to 10 blocks per second (BPS). Let’s explore the tentative roadmap for Crescendo and the process of deploying it in detail.
Crescendo — A Quick Overview
Source: Kaspa
Kaspa has always been transparent about its operations, processes, and features. Kaspa recently shared its hard fork, Crescendo’s timeline, and detailed phases. Let’s explore them.
Phase 1 — Launch & Stabilize
This phase involves launching and stabilizing a testnet (test network) with the desired block rate and related network settings. This phase has been achieved successfully with TN11, and the existing 10 BPS Kaspa testnet has been operational since January 2024.
Phase 2 — Identify Bottlenecks
Phase 2 is all about identifying the bottlenecks in the process and optimizing it to reduce the hardware specifications for running a node. This phase has also been completed successfully.
Phase 3 — Iterative Improvement
The next phase, Phase 3, involves repeating the steps mentioned in the first two phases until the minimal specs are affordable to maintain the decentralization of the mainnet (main network). This phase is almost done, and developers are getting close to the convergence of the optimization loop. The approximate time required is two months, which will be in October or November 2024.
Phase 4 — Enhanced User Experience
Phase 4 involves enhancing the node software to enrich the user experience required by mainnet operators. All minor problems encountered in the testnet settings should be addressed and fine-tuned for a better user experience. The approximate time limit for this is three months from now, which will be November or December 2024.
Phase 5 — Additional Features
Phase 5 involves implementing any additional hard fork features and deploying them on TN11. The deadline for this phase is around 4 to 5 months. However, the development team may exclude a few features to meet the deadline.
Phase 6 — Finalization
It involves multiple steps.
~ Feature freeze
~ Implement the hard fork transitioning version.
~ Deploy the transition version on TN10 to simulate the mainnet transition
~ Deploy the mainnet with hard fork transition. It may take two months.
Deep Dive into Crescendo
RK developers are into creating a mainnet version with enhanced mempool features to meet the requirements listed by the KRC-20 beta launch. The intricate features in the mainnet version include RBF (replace by fee) and a fee estimation API. Both of these features are intricate and demand ecosystem developers.
Once the version is released, the next step is to create a performance-oriented version by stabilizing TN11 nodes. The idea is to align TN11 participants with a better version by addressing all bottlenecks and offering a smooth network.
The idea is to merge the following PRs.
~ Computing Ghostdag on higher levels only on demand
~ Parallel input validation
~ Upgrade the KIP9 formula on TN11
~ Implement KIP10, compounding addresses, encouraging microtransactions with KIP9.
~ Enhanced logic for transaction sampling.
Once the above features are merged, TN11 will be an entirely new version that can run under maximum load for a few weeks. This will enable the development team to better understand the system requirements required to run such nodes.
However, if the team cannot address system requirements, specific parameters like difficulty adjustment window size, sample rates, finality depth, etc., should be adjusted. The team will further do a few more weeks of testing and performance analysis.
Testing Period
The testing phase will involve the following work.
~ Enhance the IBD process by addressing a few edge cases in the new node sync process. These cases are often rare on the mainnet but will be aggravated by higher BPS and shorter pruning periods.
~ Improve finality rules and new node headers-proof validation process, KIP7 and KIP8.
~ Cryptographic receipts, KIP6 allows smaller and simpler proof, an arbitrarily old transaction confirmation.
~ Enable transaction payloads, which optimize specifications like KRC-20.
Once the testing phase is done, the development team will work on creating a mainnet version of the hard fork. It is an intricate and detailed process that involves making crucial decisions.
Final Words
Kaspa clarifies on its website that the Crescendo plan detailed here is tentative and not a finalized roadmap. The idea is to highlight that the 10BPS hard fork is the primary focus of the development team, and the team will do its best to meet the goal.
However, network security and stability will stay unchanged regardless of the hard fork. Kaspa recommends wallet developers, mining pools, crypto exchanges, and block explorers fine-tune their settings by testing their software components via the 10 BPS testnet.
FAQs
1. Will the hard fork affect user funds or the Kaspa emission schedule?
The increase in 10 BPS will result in ten times more rewards. However, the rewards per block will remain the same, maintaining the same emission rate.
2. What exactly does hard fork mean in Kaspa’s context?
A hard fork means community-agreed and scheduled upgradations in the consensus protocol instead of a contentious fork due to disagreements among network participants.
