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.

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)