With the successful deployment of the Rusty Kaspa (RK) node software (stable release), and its broad adoption by Kaspa’s P2P network and mining community (~97% of Kaspa blocks are mined via RK nodes), the core open-source development team is now starting to prepare for a hard-fork¹ that will, among other things, increase the block rate of the network from 1 to 10 blocks-per-second (BPS)². In this post, I outline the tentative roadmap for the upcoming hard-fork, hereby named the Crescendo Hard-Fork, what it will likely include, and the process of deploying it.

Overview

At a high level, here’s how we envision the steps needed to implement such an acceleration on Kaspa’s main network. The process involves the following iterative phases:

• Launch & stabilize: Launch a testnet with the desired block rate and related network settings, and work on stabilizing it. This has been accomplished with TN11, the existing 10-BPS Kaspa testnet, which has been operational since January 7, 2024. (Done).

• Identify bottlenecks: Iteratively identify processing bottlenecks and make performance optimizations to lower the hardware specifications required for running a node. (Done)

• Iterative improvement: Repeat the above until the minimal specs are affordable enough and low enough to satisfy the decentralization required for the mainnet. (We are here, getting close to the convergence of this optimization loop. Approximate timeline: ~2 months from now.

• Enhanced user experience: Once performance requirements are settled, perfect the node software to the level of user experience required by mainnet operators. That is, some minor problems that can be neglected in a testnet setting need to be addressed here (~3 months from now). (Next)

• Additional features: Implement any additional hardfork features and deploy them on TN11. (Target timeline: ~4–5 months from now. Some features might be excluded to fit the timeline.)

• Feature freeze.

• Hardfork version: Implement the hardfork transitioning version.

• Deploy transition testnet: Deploy the transition version on TN10 (1 BPS testnet) to simulate the mainnet transition.

• Mainnet deployment with hardfork transitioning activated 1–2 months later

A more detailed walkthrough

Currently, RK developers are busy with preparing a mainnet version that is focused on introducing many mempool features whose necessity was detailed by the KRC-20 beta launch. These include delicate features such as RBF (replace-by-fee) and a fee estimation API, both of which require careful work with ecosystem developers.

After this version is released³, focus will shift to creating a performance oriented version meant to stabilize TN11 nodes. This version will be used to align TN11 participants behind a version which hopefully solves all current processing bottlenecks and provides a smooth operation of the network as a whole.
The main bulk of work would be to merge the following existing PRs:

• Computing GHOSTDAG on higher levels only on-demand while creating a pruning proof. This is a significant yet delicate PR that still requires a thorough review before merging.

• Parallel input validation, introduces finer granularity when processing transactions by validating inputs in parallel.

• Upgrading the KIP9 formula on TN11 to its final form (TN11 was launched with a premature version of KIP9).

• An implementation of KIP10, compounding addresses, allowing microtransactions with KIP9, see here.

• An improved logic for transaction sampling while building block templates

After these features are merged, TN11 will be rolled out with this new version, and run under maximum load for a few weeks. This will allow us to understand the system requirements required to run such a node. If the minimal system requirements are deemed too high, some parameters (such as difficulty adjustment window size and sample rates, finality depth, etc) will have to be adjusted, followed by a few more weeks of testing. Alternatively, further performance cycles might be considered.

During the testing period, work will resume on some other features including:

• Improving and perfecting the IBD process, addressing some edge-cases in the new node sync process that are extremely rare on mainnet, but will be exacerbated with higher BPS and shorter pruning periods.

• Improvements of finality rules and new node headers-proof validation process (KIP7, KIP8).

• Cryptographic receipts (KIP6), a modification that allows a much smaller and simpler proof that an arbitrarily old transaction was confirmed.

• Enabling transaction payloads, which will streamline specifications such as KRC-20.

Once all of the above is completed, we can start with the process of writing a mainnet version of this hard-fork. This version will have to include the logic for transitioning from the current protocol parameters to the new ones. This is an intricate process that will have to be heavily tested and involves making some crucial decisions such as when the HF will go into effect, and whether it should be done gradually or in one hit.

We emphasize that the plan outlined above is tentative. The purpose of this post is not to present a finalized, set-in-stone roadmap, but to highlight that the 10BPS hard-fork is the next major focus for the core team and that significant effort will be devoted to meeting this target. Above all, our guiding principles remain unchanged: network security and stability, and allowing sufficient time for the ecosystem to adapt. In the same spirit, we note that while the above details pertain to the responsibilities of the core developers, the broader ecosystem — including wallet developers, pools, exchanges, block explorers, and others — will also need to make adjustments, and should actively engage in this effort by testing their software components in the 10-BPS testnet.

References:

¹In our context, “hard-fork” refers to a community-agreed and scheduled change in the consensus protocol, rather than a contentious fork resulting from disagreements within the network.

²None of the changes included in this hard-fork will affect user funds or the emission schedule. The increase to 10 BPS will result in ten times more rewards, but the reward per block will be reduced by the same factor, maintaining the same emission rate per second.

³A mempool-focused mainnet release candidate version is expected by the end of this week (~August 25th).