Secure multi-party computation (MPC) and zero-knowledge databases are often shortlisted for the same project, then confused for each other. They are adjacent — both let you compute on data nobody fully discloses — but they answer different questions. Choosing wrong is expensive. This is the distinction, and the decision rule.
What each one is
MPC is a protocol run between N parties. Each holds a private input. Together they compute an agreed function — a sum, an intersection, a model — such that everyone learns the output and no one learns anyone else's input. Security rests on a non-collusion assumption: as long as fewer than some threshold t of the parties collude, inputs stay private.
zkDB involves one party that holds the data and one or more verifiers who consume an answer. The owner computes the answer and a zero-knowledge proof of its correctness against a committed dataset. Verifiers check the proof; they learn the answer and its validity, and nothing about the underlying rows. Security rests on mathematics — no non-collusion assumption, no peers.
The axis that separates them
The clean way to keep them apart is to ask which direction the trust runs.
- MPC is horizontal trust. Peers who don't trust each other compute a shared result. The hard problem is keeping inputs private from co-participants.
- zkDB is vertical trust. A producer proves something to a consumer — a regulator, an auditor, a counterparty — who was not part of the computation and may not trust the producer at all. The hard problem is convincing an outsider without disclosure.
| Property | zkDB | MPC |
|---|---|---|
| Who holds the data | One owner | Split across N parties |
| Trust direction | Producer → third-party verifier | Peer ↔ peer |
| Core guarantee | Verifiability + selective privacy | Input confidentiality among parties |
| Trust assumption | Mathematics | ≤ t parties collude |
| Proves to an outsider | Yes — transferable artifact | Not natively |
| Coordination cost | None at verify time | High — interactive, network-bound |
| Output transferable | Yes (non-interactive) | Tied to the session |
When to use MPC
- A consortium must compute a joint result over inputs no single member can hold — cross-bank fraud signals, inter-hospital clinical aggregates, joint key management.
- No party can legally or commercially be the custodian of everyone's data.
- The participants and the function are stable enough to justify the coordination overhead.
When to use zkDB
- A single data owner must convince an outsider — regulator, counterparty, court, customer — that a result is correct.
- The proof needs to survive the session: filed, archived, forwarded, re-verified years later.
- You cannot accept a non-collusion assumption; the verifier wants certainty rooted in mathematics, not in the honesty of t parties.
They compose
The most powerful regulated architectures use both. A consortium runs an MPC protocol to compute a joint statistic across members; each member attaches a zkDB proof that its own contribution was correctly derived from its committed dataset. MPC provides confidentiality among the peers; zkDB provides verifiability to the regulator who ultimately consumes the result — and who was never part of the computation.
That layering is common in practice: MPC for the horizontal problem, zkDB for the vertical one. If a project needs both "compute together in secret" and "prove the result to an outsider," it needs both technologies, at different layers — not a choice between them.
What to read next
- zkDB vs FHE vs TEE — the full five-way decision tree.
- zkDB vs differential privacy — protecting the answer versus proving it.
- The trust topology of a zkDB — who trusts whom, before and after.