docs: settle the storage engine and proof retention window

[adust09]

Why

verity-db was specified only as "an embedded key-value store" — no engine named, no retention policy. That is the largest storage decision still open, and implementation starts on top of it.

What decides it

Measured from leanSpec's fixtures-prod-scheme.tar.gz release asset (latest, 2026-07-30). The store holds two workloads with opposite shapes:

Workload	Value size	Volume	Lifetime
Blocks, states, indices, finalized anchor	~100 B – 800 B	~5 MB/day	permanent
Aggregate proofs (MultiMessageAggregate)	155–236 KB, median 190 KB	~4.1 GB/day	pruned after ~1 day

Writing six-figure-byte values continuously and dropping them en masse a day later is what an LSM tree with range tombstones is built for. RocksDB, behind a backend trait with an in-memory sibling (ethlambda's StorageBackend split) so the engine stays replaceable. Same family as ethlambda, zeam, qlean-mini; gean uses Pebble.

Note the devnet-scheme fixtures in the leanSpec source tree are much smaller and will mislead — XMSS signature is 424 B there versus 2,536 B in the production scheme.

Retention: 21,600 slots (~1 day)

Proofs get their own table keyed slot ‖ root, so pruning is a slot-ordered range delete rather than a scan, and only below tip_slot − 21,600 once that cutoff is finalized.

The floor is not ours to pick: leanSpec sets MIN_SLOTS_FOR_BLOCK_REQUESTS = 3600 (4 hours) and a BlocksByRange responder MUST serve that window. One day is an operational choice 6× above it — how far a peer can fall behind and still catch up over P2P instead of needing a checkpoint. leanSpec's own reference node meets the requirement in memory and persists no proofs at all; Verity persists them so the guarantee survives a restart.

Also

Names both signature suppliers where the docs named only one: leanSig for per-validator XMSS sign/verify, leanMultisig for aggregation and aggregate-proof verification, both behind verity-crypto's single capability contract.

Verification

• mdbook build clean; #storage-engine-and-retention anchor generated in the rendered page.
• docs/src/reference/architecture.md re-synced with the canonical root ARCHITECTURE.md; the only remaining differences are the pre-existing relative-vs-GitHub link forms the mirror header describes.