Why BLAKE3 and not SHA-256
Up to 0.7 the chunk digest was SHA-256. Creating an archive from a warm page cache topped out at about 1.2 GB/s on a Ryzen 5900X, and profiling put roughly 70% of wall time in the hash. The disk on that machine does 3.4 GB/s, so the tool was slower than the hardware it ran on for no good reason.
Measurements
Single-threaded, 8 GiB of random data from tmpfs, digest only:
SHA-256 (crypto/sha256, SHA-NI) 1.31 GB/s
BLAKE3 (1 thread) 2.88 GB/s
BLAKE3 (8 threads) 9.60 GB/sEnd to end, creating an archive of the 1.2 GiB container rootfs tree:
0.7.2 SHA-256 4.12 s
0.8.0 BLAKE3 1.74 sWhat made it easy
Chunk digests in Haven are used for identity and integrity within a store you control. They are not signatures and there is no adversary choosing inputs to collide. That means the decision was about speed and tree-hashing, not about cryptographic pedigree, which narrowed it considerably.
BLAKE3's internal tree structure also parallelises within a single large file, which SHA-256 cannot. Since chunk sizes average 64 KiB the per-chunk win is modest, but manifest hashing over a large tree benefits directly.
What it cost
Format version 2 was required, because digest length and the algorithm
identifier both live in the chunk index. Archives written by 0.7 and earlier can
still be read; haven extract dispatches on the version byte. Writing
version 1 archives is no longer possible.
The other cost is a dependency. SHA-256 is in the standard library and BLAKE3 is not, which for a tool that advertises having no dependencies is a slightly awkward thing to have to explain. It is vendored and pinned.
Would we do it again
Yes, though the honest framing is that this mattered because we had already removed every other bottleneck. Anyone whose archives live on network storage will not notice the difference at all.