Multi-Party Computation

What MPC provides

Three parties want the average of their salaries without revealing them. A bank wants to know if a customer's wallet balance exceeds a threshold without learning the balance. A genomics consortium wants population statistics without pooling raw genomes. A signing committee wants a Bitcoin transaction signed without any single member holding the key.

All of these are MPC. The shared abstraction:

party_1 (input x_1) ─┐
party_2 (input x_2) ─┼─► joint protocol ─► f(x_1, x_2, …, x_n) ─► all parties
…                    │
party_n (input x_n) ─┘

What's hidden: every input except your own. What's revealed: only f's output (and whatever the output reveals about inputs).

Security models

Practical systems pick a point on these axes. Threshold signatures (FROST, GG20) typically target malicious plus dishonest-majority, the strongest model with the most overhead.

Foundational techniques

Secret sharing

A secret s split into n shares such that any t reconstruct it; t-1 reveal nothing. Shamir's Secret Sharing (1979) does this with polynomial interpolation:

P(x) = s + a_1·x + a_2·x² + … + a_{t-1}·x^{t-1}   (random a_i)
share_i = P(i)

Reconstruction: Lagrange interpolation over any t shares.

Garbled circuits (Yao, 1986)

For two-party computation: encode the function as a Boolean circuit, garble each gate's truth table with random keys, send to the evaluator. The evaluator decrypts only the path corresponding to the inputs and never sees intermediate wire values. Modern variants: half-gates, fixed-key AES (free XOR).

Oblivious Transfer (OT)

Sender has two messages m_0, m_1; receiver has a bit b. Receiver learns m_b; sender learns nothing about b. The bedrock primitive: virtually all 2PC reduces to OT. OT extension makes large numbers of OTs cheap.

BGW / GMW protocols

Honest-majority arithmetic circuit MPC via additive secret sharing of inputs and per-gate communication for multiplications. Foundation of practical honest-majority systems.

SPDZ

Dishonest-majority MPC with information-theoretic MACs to detect malicious behavior. Active-secure even when n−1 parties are malicious. Used for high-stakes joint computation in industry.

Threshold cryptography

A specialization of MPC: instead of a generic f, the function is a cryptographic operation (signing, decryption). Properties:

• Threshold signatures. t of n parties cooperate to sign; t−1 cannot. The output looks identical to a normal single-key signature (no on-chain flag that it's threshold).
• Threshold decryption. A ciphertext encrypted to a threshold key is decrypted only with t cooperating partial decryptions.

Schnorr threshold (FROST)

Komlo & Goldberg (2020), standardized as RFC 9591 (2024). Two-round signing protocol with several ciphersuites, including Ed25519 and secp256k1. Bitcoin Taproot requires BIP-340-compatible handling; generic RFC 9591 secp256k1 signatures are not a drop-in replacement. Used for:

• Bitcoin Taproot multisig that looks like single-sig on-chain.
• Nostr threshold key custody (research and early production).
• Lightning node operator key sharding.

FROST supports threshold signing; MuSig2 is an n-of-n multisignature protocol. They address different participation requirements.

ECDSA threshold (GG20, CMP)

Gennaro-Goldfeder 2018/2020 and follow-ups. ECDSA is harder to threshold than Schnorr because of its non-linear structure; protocols are more complex with more rounds. Used by:

• Fireblocks, Coinbase Custody, Anchorage for institutional key custody.
• Bitcoin pre-Taproot multi-party signing where on-chain visibility of a multisig is unacceptable.

MuSig2

Schnorr multi-signature aggregation (BIP-327). Two rounds, n-of-n only. Differs from FROST in that all signers must participate; FROST tolerates t < n.

Use cases by adversary class

MPC vs FHE vs ZK vs TEE

These primitives often get conflated. Quick distinction:

They compose. FHE+MPC distributes the FHE secret key across parties so no single one can decrypt. ZK+MPC lets parties produce a proof neither would produce alone. TEE+MPC lowers the threshold (each TEE-attested party is harder to corrupt than a software-only party).

Production libraries

Operational patterns

Threshold custody

Replace 2-of-3 hardware-wallet multisig with a 2-of-3 FROST signing committee where the on-chain output is a single Schnorr signature. Trade-offs: better privacy and cheaper on-chain, but more protocol complexity off-chain (signers must coordinate two rounds for each signature).

Distributed trusted setup

Generate Groth16 or PLONK trusted setup parameters via MPC ceremony (the "Powers of Tau"). Any single honest contributor among thousands suffices for soundness. Used by Zcash, Filecoin, Aleo, Aztec.

Confidential ML inference (MPC variant)

Two non-colluding servers each hold a share of the model weights and the input. Inference proceeds with per-layer MPC arithmetic. Trade-off vs FHE: faster (often by orders of magnitude) but requires a non-collusion assumption.

Federated eCash mints

Fedimint distributes mint authority across guardians using threshold blind signatures. Cashu’s basic protocol uses a mint signing key and does not itself require a threshold federation.

Trade-offs

Strengths

• No single point of trust. The secret is distributed across n parties.
• Strong literature on what guarantees hold under what assumptions.
• Composable with FHE, ZK, and TEEs.
• Output indistinguishability. Threshold signatures look like normal sigs on-chain.

Limitations

• Communication-heavy. Many rounds, large messages, orders of magnitude slower than centralized computation.
• Liveness assumptions. Threshold protocols halt if too few parties online.
• Setup ceremony. Distributed key generation (DKG) is its own protocol with its own trust assumptions.
• Operational complexity. Coordinating signers across organizations is hard; tooling is improving but not consumer-grade.
• Side-channel surface. Each party's local execution leaks (timing, memory). High-stakes use needs TEE or formally-verified implementations.

Attack surface

Recent developments (2024-2026)

• FROST standardization as RFC 9591 (June 2024).
• Production threshold custody at scale (Coinbase, Fireblocks, BitGo) with billions in AUM.
• DKG ceremony tooling matured; simpler bootstrapping for new threshold groups.
• Active-secure variants of FROST and GG20 with proven simulators.
• Mobile MPC SDKs (ZenGo, Lit Protocol). Distributed wallets without hardware keys.
• MPC-in-the-head signature schemes (such as Picnic) explored for PQ.

Primary sources

• Yao: Protocols for Secure Computations
• Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation
• Multiparty Computation from Somewhat Homomorphic Encryption
• FROST: Flexible Round-Optimized Schnorr Threshold Signatures
• RFC 9591: FROST
• UC Non-Interactive, Proactive, Threshold ECDSA
• Secure Multiparty Computation (MPC)
• MP-SPDZ implementation
• FROST implementation
• MuSig2: BIP 327
• Fedimint protocol
• Cashu NUT-00
• Fast Secure Two-Party ECDSA Signing