Zero-knowledge databases, explained from first principles.
The reference on zero-knowledge databases — what they are, how a SQL query becomes a verifiable proof, and where the technology fits among FHE, MPC, TEEs, and differential privacy.
01Foundations
The primitives. Start here if the field is new.
What is a zero-knowledge database?
A plain-English guide for CTOs, CISOs, and data architects. Definitions, mechanism, performance, and where it fits next to FHE, MPC, TEEs, and differential privacy.
Zero-knowledge proofs, explained
The cryptographic primitive underneath everything zkDB does — completeness, soundness, and the zero-knowledge property — in plain English for technical decision-makers.
Polynomial commitments: KZG and IPA
How a dataset is reduced to a short, tamper-evident fingerprint — the commitment scheme that lets a zero-knowledge proof refer to data it never reveals.
02Mechanism
How a query becomes a proof, gate by gate.
How a verifiable query actually works
A 10-minute primer on the cryptographic mechanics of a zero-knowledge SQL query — commitment, circuit construction, proving, and verification.
Custom gates for SQL: how a query becomes a circuit
Why PLONKish arithmetization — not generic R1CS — is the right substrate for verifiable databases, and how each SQL operator compiles to a hand-tuned custom gate in Halo2.
Lookup arguments: proving membership without scanning
The second half of PLONKish — how a circuit checks that a value lives in a table in time independent of the table's size, and why it makes verifiable SQL practical.
03Comparisons
Where zkDB sits among privacy-enhancing technologies.
zkDB vs FHE vs TEE: a decision tree for architects
Five privacy-enhancing technologies. Five different guarantees. A direct comparison of zero-knowledge databases against homomorphic encryption, secure multi-party computation, trusted execution environments, and differential privacy.
zkDB vs MPC: when computation must be shared
Secure multi-party computation and zero-knowledge databases solve adjacent but different problems — confidentiality among peers versus verifiability to a third party. A decision guide for architects.
zkDB vs differential privacy: protecting the answer vs proving it
Differential privacy protects the people inside the answer; a zero-knowledge database proves the answer is honest. They are not rivals — they are two halves of a trustworthy statistic.
zkDB and blockchain: verifiable data without going on-chain
Zero-knowledge proofs grew up securing public blockchains — but a zero-knowledge database needs no chain, no token, and no on-chain data. How the two relate, where they differ, and the one place they meet.
04Architecture
What changes for trust, audit, and compliance.
How the pieces fit together.
Each idea below answers a why, not just a what — the role it plays in turning a private query into a public proof. Follow any one for the full treatment.
For decades, being convinced of a claim and seeing the data behind it were the same act. A zero-knowledge proof severs that link — a claim becomes checkable without the data ever changing hands. Everything else here is built on it.
A proof must be about the real dataset, not a convenient substitute. A commitment reduces the data to a short fingerprint, published once; alter a single row afterward and every proof against it fails. KZG keeps proofs tiny but needs a setup ceremony; IPA needs none.
A proof system cannot reason about SQL directly — the query must first become polynomial constraints. PLONKish is the translation style that makes this efficient for databases, because it admits custom gates and lookups instead of forcing everything through generic multiplication.
Each SQL operator — a filter, a join, an aggregate — has its own algebra. A custom gate encodes one operator as a purpose-built constraint, and the gates compose into a circuit the way a query planner composes operators. That gate library is the durable asset across engagements.
Range checks (WHERE … BETWEEN) and set membership (IN) are ruinously expensive in older proof systems. A lookup proves a value sits in a precomputed table in time independent of the table’s size — turning the most common predicates from a bottleneck into a single step.
The framework that takes these primitives to production. zkDB circuits are built on it; it offers transparent proofs (no setup) or succinct ones (small, with a ceremony), and folds long query pipelines into a single short proof through recursion.
The deepest change is institutional, not mathematical. Verifiability collapses the chain of auditors, attestations, and vendor assurances into one artifact anyone can check — turning trust from something you extend into something you compute.