KIP-24: Transaction ID v1 Hashing (BLAKE3, payload/rest split)

[biryukovmaxim]

KIP-24: Transaction ID v1 Hashing (BLAKE3, payload/rest split)

Specifies a new transaction ID computation for version 1 transactions. Version 0 txids are kept verbatim (BLAKE2b); version 1 txids are computed with keyed BLAKE3 as TransactionV1Id(payload_digest || rest_digest), hashing the payload independently from the rest of the transaction body.

Motivation

• Performance: BLAKE3 is faster than BLAKE2b on native hardware (slightly on small inputs, up to ~3x on large payloads).
• Provable payload: splitting the payload into its own digest lets ZK guests and L2/based executors prove (or skip) a transaction by its payload without bringing the full transaction body, linking it to the block's accepted_id_merkle_root (KIP-15).

Design highlights

• New hashing is gated on a version bump, not applied in place: v0 logic is untouched, so the change is non-breaking and a participant opts in by building a v1 transaction. KIP-21 relies on the version field to efficiently distinguish v0/v1 when proving over the sequencing commitment.
• A minimal two-leaf scheme (payload leaf + flat "rest" leaf) was chosen over a richer Merkle tree, which benchmarked at ~2x the common-case cost for no practical benefit.
• The hash-function choice is presented as an explicit two-domain tradeoff (native execution vs. RISC0 ZK guest, where SHA-256 has a precompile); BLAKE3 is chosen as the best "good enough in any guest" option while winning on the ubiquitous native path.

Status

Implemented in rusty-kaspa via kaspanet/rusty-kaspa#849.

References

• KIP-15 (sequencing commitments), KIP-20 (covenant IDs), KIP-21 (partitioned sequencing commitment / lanes).