Decision
Every blob is identified by its BLAKE3 hash. Clients and nodes verify received bytes against the known hash on every transfer. The hash→backend mapping is internal to each origin-backed node and never shared — no participant in the network can learn or bypass the node’s backing storage.Why BLAKE3
- Fast. Several GB/s on modern hardware — faster than SHA-256, often limited by memory bandwidth rather than CPU.
- Tree-structured. The BLAKE3 hash tree enables streaming verification: a client can verify chunks as they arrive rather than waiting for the full blob.
Verified streaming
Delivery uses bao — an interleaved verified-stream encoding of the BLAKE3 tree. Thecdn/client/v1 paid-delivery payload is always bao bytes: content interleaved with the hash proofs needed to verify each 16 KiB chunk group against the root the client expects. The bao decoder verifies every chunk group as it arrives. A malicious node cannot insert a single corrupt byte and still earn — the client rejects the stream before paying for that chunk group.
Because every chunk group carries its own proof, a resumed or ranged fetch verifies independently — the decoder aligns the requested offset down to its 16 KiB chunk-group boundary, so there’s no need to re-read from the start. Payment meters all transmitted bytes, including the proof bytes: the verification overhead is roughly 0.4% of blob size, not free metadata.
An origin-cold node must import or build the blob’s outboard (its BLAKE3 tree) before it can serve verified ranges. Node-to-node cache-miss pulls stay bao-encoded and pipelined end to end.