Kaspa virtual relations by level were refactored in rusty-kaspa PR #765 by compressing repeated parents_by_level entries with run-length encoding. Merged on November 26, 2025, the change reduces redundant in-memory and database representation, reads legacy headers through a fallback path, and carries an important warning: the upgraded database cannot be reopened by older software.

Key takeaways

• Kaspa block headers can repeat the same parent set across several block levels; the patch stores those runs once with cumulative counts.
• A new CompressedParents type replaces the internal Vec<Vec<Hash>> representation while preserving expanded access and conversion paths.
• The author reported about 80% header-size reduction in a sample of five random headers, not a network-wide benchmark.
• Existing databases are read through a fallback and converted in memory, while new headers are written under a new compressed prefix.
• Upgrade is described as automatic, but downgrade is not: returning to an older build requires deleting and rebuilding the database.

What are Kaspa parents by level?

Kaspa’s BlockDAG does not organize history as a single-parent chain. A block header carries parent relationships, and parents_by_level represents parent sets across the block levels used by the protocol’s hierarchical structures. Adjacent levels can contain identical parent sets, creating repeated data inside the header representation.

The merged rusty-kaspa PR #765 targets that repetition. It continues work from PR #744 and introduces run-length encoding, or RLE, for the field. Instead of storing the same vector separately for every level, the implementation stores a parent set together with a cumulative level count that indicates how far its run extends.

How does CompressedParents work?

The old core field used Vec<Vec<Hash>>. PR #765 replaces it with CompressedParents, whose entries pair a cumulative u8 count with a parent vector. When several successive levels have identical parents, one entry can represent the entire run. The source adds iterators for run-length encoding and expansion, plus direct-parent and indexed-access helpers.

The implementation uses binary search against cumulative counts when retrieving a level. It also rejects representations exceeding 255 levels, matching the range available to the cumulative u8 value. Conversion code expands or validates the structure when moving between consensus, RPC, gRPC and JavaScript-facing models.

Those details matter because compression must remain transparent to code that needs a particular level. A smaller stored representation is only useful if hashing, validation, mining templates and external conversions continue to agree on the same logical sequence.

How large was the claimed reduction?

The pull request author reports that, based on five randomly selected headers, RLE reduced header size by approximately 80%. That is a useful motivation signal: repeated parent sets are common enough in the small sample to make compression substantial.

It is not a production benchmark. Five headers cannot establish an average across network history, different block levels or future conditions. The PR also contains no end-to-end measurements for database size, I/O latency, synchronization time, memory use or CPU cost. RLE reduces redundancy, but expansion, conversion and lookup add their own work.

The responsible conclusion is narrow: the new representation compressed the author’s sample strongly and was accepted after code review and tests. A claim that every node saves 80% of total disk space would be false, because headers are only one component of node storage.

How are existing databases upgraded?

The database change uses separate prefixes. DbHeadersStore first attempts to read the new compressed-header prefix. If the record is absent, it falls back to the legacy header prefix, deserializes temporary legacy structures and converts their parent vectors into CompressedParents in memory. New header records are always written in the compressed format.

This approach avoids a blocking migration that rewrites the entire historical header store before startup. The PR describes the upgrade as automatic and instant because old entries can be read lazily through fallback logic.

The compatibility is one-way. Once the database receives headers under the new prefix, an older rusty-kaspa build does not understand that storage format. The source warning says that reverting to master from before the change requires deleting the database. Operators should therefore treat the upgrade as a database-format boundary, even though it does not require an interactive migration step.

What should node operators do before upgrading?

Pin the exact release or commit you intend to run and read its release notes. Stop the node cleanly, preserve configuration and logs, confirm available disk space for recovery, and make a backup only if your operational policy can restore and validate it. Do not assume that swapping an old binary back into place is a safe rollback.

Test monitoring, RPC consumers and any locally built tooling on a non-critical node. The diff touches 29 files across consensus core, database access, hashing, RPC conversion, WASM, integration tests and daemon code—602 additions and 218 deletions according to GitHub. That breadth is expected for a core representation change.

The smaller Kaspa script vector optimization illustrates a related but distinct principle: internal collection changes require boundary tests. PR #765 has a larger compatibility surface because it also changes persisted header storage.

What does this mean for Kaspa’s roadmap and price?

Efficient header representation can support long-term node engineering by reducing redundant data and making internal structures more deliberate. It is part of maintainability work that can help the implementation scale as history grows. However, PR #765 is not a block-rate upgrade, a tokenomics change or evidence of new merchant demand.

Technical progress may inform a fundamental assessment, but this single refactor cannot determine KAS price. Price also reflects liquidity, market structure, adoption, regulation and broader risk conditions. The later Kaspa roadmap discussion at TOKENIZE London should likewise be read as roadmap context rather than a guaranteed market outcome.

For community readers who want a tangible conversation starter, KaspaBuy’s existing guide to where to buy Kaspa merchandise is separate from protocol analysis; merchandise supports identity and education, not technical validation.

Frequently asked questions

Did PR #765 change the parents of historical blocks?

No. It changes how parent sets are represented and stored by rusty-kaspa. The logical expanded relationships must remain equivalent for hashing, validation and RPC conversion.

Can an older node binary open the upgraded database?

The PR warns that it cannot safely do so after new-format records are written. Reverting requires deleting and resynchronizing the database unless newer official guidance provides another supported procedure.

Does “80% smaller” mean the entire node database shrinks by 80%?

No. The figure came from five sampled headers and refers to the compressed header representation. It is not a measurement of the complete database or every header.

Source and verification note

This article is grounded in kaspanet’s merged rusty-kaspa PR #765, merged November 26, 2025. The PR description documents RLE motivation, the five-header sample, CompressedParents, fallback reads and the downgrade warning. Its public diff records 29 files, 602 additions and 218 deletions. Performance and roadmap implications above are bounded analysis; verify database procedures against the exact release you deploy.