Eval for Gale / Ingot / Dusk. Zig NIFs: blake3/1 (32-byte digest), xxh3/1 (u64), hash64/1 (FNV-1a, kept).
Roles
| Hash | Crypto | Typical throughput | Use here |
|---|---|---|---|
| BLAKE3 | Yes (256-bit, Merkle tree) | ~3–8 GB/s/core, scales across cores | S5 blob CIDs, S3 x-amz-meta-blake3, Iroh blob ids, integrity |
| XXH3-64 | No | ~15–30 GB/s/core | Cluster routing, cache keys, hot checksums |
| FNV-1a 64 | No | ~1–2 GB/s | Legacy hash64/1 |
| SHA-256 | Yes | ~0.8–3 GB/s | AWS SigV4 payload hash only (S3 protocol requires it) |
Decision
- Storage identity is BLAKE3. S5 (and Iroh blobs) already use it. Same digest as
b3sum. Collision-resistant; verified streaming via the Bao/Merkle layout later if we stream. - Do not use XXH3 as a content id. Fast and excellent for maps, not for adversarial or cross-trust storage.
- S3 stays location-addressed. Key defaults to hex(BLAKE3). SigV4 still SHA-256. Metadata carries blake3 + xxh3.
- S5 is content-addressed. CID
0x5b 0x82 0x1e+ 32-byte BLAKE3 + LEB128 size. HTTP/s5/uploadand/s5/blob/{hex}. - Keep FNV
hash64/1so existing cluster ticks do not change.
S3 vs S5
- S3: any MinIO/AWS/R2 endpoint, SigV4 or unsigned. Fast PUT of opaque objects. Overlay CAS by hashing first.
- S5: CAS network (often on Iroh). Fetch by hash, verify every byte with BLAKE3. S3 can be an S5 backend, not the identity layer.
Zig std.crypto.hash.Blake3 is slower than the official Rust/C+asm b3sum (~1 GB/s vs ~4 GB/s on some ARM). Good enough for Elixir NIF blobs; we can swap in C blake3 later if storage is the bottleneck.