When NOT to use MPC

Why this matters

MPC is between 10^3 and 10^7 times slower than plaintext computation, depending on the protocol and the function. It's also harder to operate — every bug becomes a security bug, latency is a function of network RTT, and malicious security adds more overhead on top. Before reaching for MPC, you should have a clear reason why simpler tools — contracts, audits, trusted hardware, ZK, differential privacy, federated learning, plain hashing — don't solve your problem. Many of the 'we need MPC' asks in industry are actually 'we need a better data-sharing contract'.

Demo

A cheat-sheet of alternatives. For each, one sentence on when it wins and when it falls over.

Alternative              | Wins when                                     | Falls over when
-------------------------|-----------------------------------------------|------------------------------------------
Trusted third party      | Party exists + incentive-aligned              | No trustworthy referee, or liability concerns
Data-use contract + audit| Parties under legal framework (banks, gov)    | Audits are after-the-fact; damage done
Hashes / deterministic   | Set intersection with many dupes ok to leak   | Adversary can enumerate input space
TEE (SGX, Nitro)         | One party trusted-ish; centralized compute    | Side-channels, attestation chain, vendor trust
Differential privacy     | Statistical queries on aggregates             | Per-individual answers or joins
ZK proofs                | One prover convincing many verifiers          | Multi-input joint computation without a prover
FHE                      | Non-interactive compute on encrypted data     | Bandwidth + slow (~10^6 slower than plaintext)
MPC                      | Multi-input joint, no trusted party           | Round complexity + latency on WAN
 
Rule of thumb: MPC earns its slot when (a) there are ≥2 non-trusting inputs,
(b) the function is meaningful only on joint data, and (c) a trusted third
party is legally, commercially, or politically impossible.

Try it yourself

1. For the three problems you wrote down in Task 1, check each against the cheat sheet. For any where a non-MPC alternative wins, write one sentence explaining which and why.
2. Benchmark: run the additive-sharing code from Task 4 with n=3 parties, 1000 inputs. Now do the same sum in plaintext. The ratio is your MPC overhead — note it. (For additive sharing alone, overhead is small; it grows sharply once you add interactive multiplication, malicious security, and real network.)
3. Pick one industry MPC deployment (Meta's private lift, Boston wage gap study, ISDA). Find the paper or blog post. Identify specifically which non-MPC alternative was ruled out, and why.
4. List three 'MPC-shaped' asks in your own work. For each, be honest: would your stakeholder accept 100× latency and 10× operational complexity? If not, you're probably not doing MPC.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

Explain the three main alternatives to MPC (trusted parties, ZK, TEEs) and name one situation where each is a better fit than MPC. Keep it concrete with named companies or products where possible.

2. Why it works (the mechanism)

Walk me through the privacy-vs-performance trade-off across {plaintext, DP, ZK, TEE, FHE, MPC}. For each, what does it assume about who you trust and what the protocol leaks? Rank them on latency, bandwidth, and trust surface.

3. Advanced — application & what's next

I'm evaluating whether to use MPC for [your specific scenario]. Go through my constraints — [enumerate: party count, network, regulatory, latency budget] — and steel-man each non-MPC alternative before recommending or ruling out MPC. If MPC wins, name specifically which protocol (semi-honest GMW? SPDZ? garbled circuits?) matches the function shape.

References

• Ion et al. — Meta's Private Lift Measurement (MPC in prod)
• Boston Women's Workforce Council — salary gap MPC study
• Evans-Kolesnikov-Rosulek Ch. 9 (applications)