All articles

Go easy on the disk. Node runners, wallets and tiny chips all gain from the latest Rusty Kaspa changes

A Kaspa node server on a desk breathing easy beside a small chip, a paged ledger and a magnifying glass over a coin
Illustration by kaspa.news, AI-generated.

Several changes have landed in Rusty Kaspa, the main Kaspa node software, since v2.1.0. None of them is in a release yet, but together they touch most people who run or build on Kaspa. A node can now write far less to its disk, wallets can fetch only what's new, and the core rules can be built for small chips with no operating system. A covenant lookup that token wallets have been waiting for is in review.

A node that writes half as much

A Kaspa node keeps its data in a database called RocksDB, and the network's ten blocks a second mean that database is busy. Constant writing wears out cheap SSDs and slows down nodes on hard drives or low-cost virtual servers.

supertypo has added a setting called lowio that trades a little extra memory for much less writing (pull request). It keeps larger buffers in memory, compresses data and stores large values separately. That way the database spends far less time rewriting its own files. In supertypo's test, a full mainnet sync from scratch wrote roughly half as many bytes as the default setting. It ran about 99% fewer database compactions, which are the background clean-ups that rewrite files on disk, and finished about 10% faster. The database ended up about the same size.

The setting is for ordinary pruned nodes, the kind most people run. It's turned on with kaspad --rocksdb-preset=lowio, and the --ram-scale option shrinks its memory use on smaller machines. supertypo reported testing it locally and on several virtual servers before proposing it (message). The numbers come from one machine with a fast NVMe drive, so results on other hardware will differ.

Wallets can ask for one page at a time

When a wallet opens, it asks a node for every coin belonging to its addresses. For a busy address that answer can be huge, and until now the wallet had to download all of it again each time.

D-Stacks rebuilt the node's coin index so a wallet can ask for coins in pages and only for a range of time (pull request). Coins are now stored in the order they arrived, so a wallet that already knows everything up to a certain point can ask only for newer coins. The new request is called get_utxos_by_addresses_v2, and the old one keeps working. kaspa.news covered this work while it was still under review, and it is now merged.

IzioDev, who merged it after reviews by Maxim Biriukov, called it the groundwork for the next step (message). Biriukov has suggested marking the old request as outdated in the next release and removing it two or three releases later, and IzioDev has opened an issue to do exactly that (issue). Node operators should know one practical thing. The index is reorganised automatically the first time an upgraded node starts, so that first start will take longer.

Finding every coin under a covenant

The next step is a lookup by covenant ID, the identity that covenant coins such as KCC-20 tokens carry. Today a wallet can ask for coins by address, but it can't ask the node for every coin belonging to one token or app.

Maxim Biriukov has opened a pull request that adds exactly that, as an optional index switched on with --covenant-index (pull request). It works page by page in the same way as the new address request. It's still in review. D-Stacks, who wrote an earlier unfinished version, has asked whether the covenant index should run independently of the address index and how its storage keys should work. Those choices are easier to make now than after a release, because changing them later would need another database migration (review notes). D-Stacks also said a minimal working version is the right approach for a change so many people are waiting for.

The rules of Kaspa, on a chip with no operating system

Biriukov's other change is quieter but reaches further (pull request). Rust programs usually rely on a standard library supplied by the operating system. Small devices such as hardware wallets often have no operating system at all. Biriukov reworked the core consensus code and the maths and hashing libraries beneath it so they can be built without that standard library. The project's automated checks now build them for a bare ARM microcontroller target to make sure that keeps working.

IzioDev explained why it matters for builders of firmware and other unusual platforms. They can rely on the libraries inside Rusty Kaspa instead of writing their own versions of the same rules (message). Fewer rewritten copies means fewer places for a mistake to hide. This is groundwork, not a new device. Normal builds are unchanged, and nothing here announces a hardware wallet.

Fixes for JavaScript wallets

IzioDev also merged a set of fixes to the wallet code that JavaScript apps use, after review by Biriukov (pull request). Fee and size calculations now follow the rules that apply since the Toccata upgrade. The transaction builder can create transactions that involve covenants, and it now tries the next coin instead of failing when one coin pushes a transaction over the size limit.

Until a release ships, JavaScript developers who need these fixes have to build the package themselves, which IzioDev described as a good exercise anyway (build guide).

Token details get a home in the standards repository

On the standards side, Manyfest's KCC-23 has been added to the KCC repository (pull request). KCC-23 is a way to tie a token's name, symbol and decimal places to its covenant ID, so a wallet can check where those details came from. kaspa.news explained the idea when it was proposed. Being in the repository makes it a draft standard with a permanent address. It isn't final, and wallets don't have to support it yet.

When it reaches you

Everything above except KCC-23 sits in the main branch of Rusty Kaspa or in review, and the latest release is still v2.1.0. People who run a node or build a wallet from the release downloads will get these changes with the next release. Anyone who wants them sooner has to build from the main branch, with the usual risk of running unreleased code.

Telegram sources link to public messages in the Kaspa Core R&D (public) Telegram channel.

More Kaspa Articles

All articles