Kaspa on Rust — First Stable Release

We are excited to announce the first stable Rusty Kaspa (RK) node Release (version 0.14.1).

This is a significant milestone for the Kaspa network, as it marks the point where we shift to a new improved and optimized engine, which can now be built upon and accelerated to its limits.

Approx. 2 years ago, when I first proposed the Rust Rewrite, I dreamed of unleashed performance and superb code quality. Today I can say that the new codebase is of highest quality possible, and that the set of individuals contributing to it is now an elite group of people, forming a decentralized and world-spread core development force.

Currently, as part of the open beta announced a few weeks ago, RK nodes already comprise ~1/4 of the P2P network, and as much as 29% of the hashrate is mined through them.

Rust nodes already comprise ~1/4 of the Kaspa network. Source: kas.fyi

Going forward, this stable release signifies the point at which we recommend RK as the main software to be running the network.

Switching to RK is crucial for major network-wide future advances such as accelerating mainnet to 10-BPS (10-BPS testnet-11 runs solely on RK nodes), upgrading to Dagknight, supporting smart-contract opcodes, etc. However, it also provides the following immediate benefits to node maintainers:

• Near-constant storage: Unlike golang nodes which only prune transaction data, RK nodes constantly prune headers as well, hence node disk usage is lower and nearly constant.
• Fast sync times: RK heavily utilizes parallelism to accelerate header and block processing. This is mostly notable during IBD where RK nodes enjoy increased processing throughput and are significantly faster.
• RPC software stack: RPC interfaces have an enhanced design and will be extended in the near future (with a fully-featured transaction index being a notable example)

Transition strategy & technical details

We aim for a gradual process where more and more nodes slowly switch to RK. The following provides detailed instructions for the upgrade based on your specific use case:

• Rust open beta participants: Version 0.14.1 contains several stability fixes for issues that have been reported over the beta testing period. It is highly recommended that you upgrade to this version as soon as you can for the reliable operation of your node (if you upgraded to 0.14.1 RC during the last week, there’s no need to take any action)
• Golang node maintainers: Pick a random number between 0–7. Wait this amount of days before you switch your node to RK. Note that RK uses a completely different database, so you'll need to resync the new RK node from the network. If possible, keep the former golang node up and running in parallel to the new node for a stability period.
• Golang archive node maintainers: RK supports a robust archival mode, but a full archive migration process was not deployed yet. If you wish to keep your archive continuous, keep the golang node for now, a DB migration process will be implemented and announced.
• Mining Pools: Pool operators who haven’t experimented yet with the RK node should begin this process and should allocate a small hashrate percentage to be mined through it. Hashrate should then gradually shift entirely to RK nodes. Large pools should coordinate the timing and hashrate percentage with the core development group.
• Exchanges (and other transaction confirmation service providers): Test the RK node in your test environments. It should work as a drop-in replacement to current golang node as it implements the same gRPC API. Get comfortable with running the node and maintaining it. Then gradually move your services to run over it. If you use kaspawallet golang CLI wallet at your backend services, upgrade to latest version (0.12.17) which was just released and is compatible with RK nodes. See the following point as well —
• Wallet developers: Follow KIP9 simplified instructions (disallow sub 0.2 KAS payments; make sure change is above 0.2 KAS by selecting larger/additional inputs if needed). Test your wallets over the RK node. A long term guide with a detailed wallet reference implementation for fully adapting wallets to KIP9 will be published in the coming weeks.
• Normal users (who only access their wallet via web or mobile app): No action needed. Be patient with wallet developers if minor problems occur when making very small payments.

The RK node has a CLI interface which is mostly identical to golang nodes. The following lists any (breaking) CLI changes:

• RPC defaults to localhost (127.0.0.1) so is not accessible externally. To restore golang-like behavior add --rpclisten=0.0.0.0
• UPnP is supported and on by default. This means nodes can be visible publicly even if launched behind a router. To disable UPnP add --disable-upnp
• Config file format has a slightly different structure, see Using a configuration file
• Configurable RAM cache usage: Node maintainers who wish to increase (or decrease) their RAM usage can set --ram-scale=1.0 to a number higher (or lower) than 1.0 respectively. This increases sync and overall node performance by using additional RAM.

Kaspa Next Generation (KNG) & WASM SDK

A rich software stack has already been built over the RK codebase. Subsequent announcements will focus on each of them separately. Here we only bring a brief summary.

KNG: Kaspa NG (KNG) — A feature-rich desktop solution that integrates the RK P2P node as well the ability to connect to the public P2P node infrastructure. KNG includes a Rusty Kaspa wallet implementation, node and network performance metrics, and a real-time Block-DAG visualizer.
KNG makes it easy for any desktop user to contribute to the network topology decentralization by powering up the local P2P node without any extensive knowledge.

WASM SDK: The WASM SDK enables the Rusty Kaspa framework to work within the WASM32 environment, making it accessible from JavaScript and TypeScript. This adaptation allows the RK framework to be used in web browsers, Node.js environments (such as Electron and NW.js), and Chrome browser extensions. The SDK includes essential tools for handling network-focused cryptographic functions, interacting with the RK peer-to-peer (P2P) nodes via WebSocket RPC, and creating wallets.

I would like to personally thank everyone who has contributed to the development and testing of this enormous project, no matter how large or small your contribution has been, and to Yonatan Sompolinsky, for dreaming about 10-BPS and beyond, and being a true inspiration. None of this would be possible without the above-mentioned community of developers and enthusiasts that had formed around this effort ❤️