Design
zkv stores a key-value log entirely on the Zcash blockchain. There is no separate database server; readers reconstruct state by scanning the chain with a viewing key and replaying the signed memos.
Chain as the source of truth
A "database" is a Unified Full Viewing Key plus a birthday height, living in
a single shielded pool (Orchard by default, or Sapling). A write is a
zero-value shielded output to the database's own address carrying a
Memo::Text that begins with the wire magic ZKV0.
Same-block ordering is (mined_height, txid, output_index); last
write wins.
ZKV0 SET zec_usd_price 1008.33 0285d48bd429fd9382bb54145ce66107c8faee6fb38c4e55fccb8d44f9c0bd542d…
Snapshot + tail replay
Scanning every memo on every read would be O(total writes). Instead a local
zkv_state.sqlite snapshot holds the projection of memos buried
past a reorg-safe depth (100 blocks); only the recent live tail is
re-verified in memory per read. The snapshot is a cache, safe to delete; it
rebuilds on the next read.
Recoverable signatures
Each write carries a 65-byte recoverable ECDSA signature, so the reader recovers the signer's pubkey from the signature itself; the memo carries no pubkey field. That's what lets a database have many authorized writers without growing the wire format.
Receiver-binding & replay protection
Signatures commit to the database's receiver (derived from the
viewing key) and a network tag, not the address text, so a memo signed for
one database, or one network, can never verify against another. Each key and
management target carries a tombstone-surviving high-water counter folded
into the signing domain, so a verbatim re-broadcast is dropped as
StaleVersion and can't revert a value or resurrect a deleted key.
Owners and writers
The root (UFVK-derived) key becomes owner #1 when INIT confirms, and is the
permanent creator. Owners may write anything and manage the
registry; writers are limited to a scope of CREATE / UPDATE / DESTROY.
Authorization is enforced identically by every reader (it's just replay), so
it holds with no central server. An owner can FINALIZE the
database, a one-way latch that seals it permanently.
Privacy caveat: the address is a viewing key. Everyone you share it with can read all values, forever, with no forward secrecy. Don't put secrets in it; it's a public, auditable KV log.