Secure Multi-Party Computation (MPC)

A specific application of MPC where a private key is split into multiple secret shares distributed among participants. No single party ever reconstructs the full key. A transaction is signed only when a pre-defined threshold (e.g., 2-of-3) of parties collaborate using their shares. This is the dominant model for MPC-based crypto wallets.

• Example: A 2-of-3 wallet setup where shares are held by a user's phone, laptop, and a cloud backup. Any two devices can sign, but a compromise of one reveals nothing.

The fundamental security guarantee. The signing key material never exists in one place, not even in memory. It is mathematically divided. This eliminates the risk of a single device compromise, insider attack, or server breach leading to total key loss. Security is distributed across multiple parties, devices, or locations.

• Contrast with Multisig: Unlike on-chain multisig, which uses multiple complete keys and leaves a public on-chain footprint, MPC's distribution is cryptographic and private.

The initial, critical protocol phase where parties collaboratively generate the key shares without a trusted dealer. Each party contributes randomness, and through a series of cryptographic exchanges, they each end up with a valid secret share of a newly created key. Crucially, no party ever knows the full private key or another party's share, establishing trust from the outset.

The core cryptographic promise: parties learn only the output of the computation (e.g., a valid signature) and nothing about each other's secret inputs. This is ensured by zero-knowledge proofs and other advanced cryptographic techniques within the MPC protocol. Input privacy holds even if some participants are malicious (adversarial security models).

MPC enables complex, policy-driven signing authorities that are enforced cryptographically. The threshold (t-of-n) can be configured for any governance model:

• 2-of-3 for individual user security
• 5-of-9 for a corporate treasury
• Geographic distribution requirements (e.g., shares in different legal jurisdictions)

Policies can be changed via a new DKG round without moving funds on-chain.

An advanced property where the collaborative signing process produces a single, standard cryptographic signature (e.g., an ECDSA signature) that is indistinguishable from one made by a regular private key. This provides:

• On-chain efficiency: Appears as a single-signer transaction, minimizing gas costs.
• Privacy: Does not reveal the multi-party nature of the wallet on the blockchain.
• Compatibility: Works with all existing wallets, explorers, and smart contracts.

A primary application of MPC in crypto, enabling decentralized key management. A private key is never assembled in one place; instead, it is split into secret shares held by multiple parties. Signing a transaction requires a pre-defined threshold (e.g., 2-of-3) of parties to collaborate using MPC, generating a valid signature without reconstructing the full key.

• Use Case: Replaces multi-sig with a single on-chain signature, reducing gas fees and complexity.
• Benefit: Eliminates single points of failure for private keys.

MPC allows blockchains to execute contracts on encrypted or private data. Parties can provide sensitive inputs (e.g., financial records, identity data) to a contract logic enforced by MPC, which computes the result (e.g., a credit score, auction winner) without exposing the underlying data.

• Example: A decentralized auction where bids remain secret until the winner is determined.
• Protocols: Implemented by networks like Secret Network and Oasis Network for confidential DeFi and data markets.

MPC is the core technology behind modern institutional and non-custodial wallets. It distributes key generation, storage, and signing across multiple devices or entities.

• How it works: The user's wallet is secured by shares held on their phone, hardware device, and a cloud backup (3-of-3 setup). Spending requires collaboration between a subset.
• Advantage over Traditional Multisig: More efficient and private on-chain, appearing as a single-signer address.
• Providers: Services like Fireblocks, Qredo, and ZenGo use MPC for enterprise-grade security.

Many cryptographic systems (e.g., zk-SNARKs) require a one-time trusted setup to generate public parameters. MPC is used to decentralize this process, ensuring that the system's security only relies on at least one participant being honest and destroying their toxic waste.

• Process: Multiple parties jointly compute the parameters, each contributing randomness. The final parameters are secure if any single participant is honest.
• Famous Example: The Perpetual Powers of Tau ceremony for zk-SNARK circuits, involving thousands of participants.

MPC networks can act as decentralized verifiers or guardians for cross-chain communication and data feeds. A committee of nodes uses MPC to collectively sign messages attesting to events on another chain or external data, without any single node holding the full signing power.

• Bridge Security: Safer than a pure multisig, as the signing key is never formed.
• Data Integrity: Used by oracles like Chainlink DECO to prove the authenticity of private web data without revealing it.

While powerful, MPC has trade-offs versus other privacy technologies like Zero-Knowledge Proofs (ZKPs).

• Computational/Network Overhead: Requires significant communication rounds between parties, making it slower than local computation.
• Liveness Assumption: Requires a majority of participants to be online and cooperative to produce a result.
• Transparency vs. Privacy: The computation logic is typically public, unlike in ZKPs where the logic can also be hidden.
• Adversarial Model: Security is defined under specific models (e.g., honest majority, malicious minority).

MPC security is defined by its adversarial model, which specifies what fraction of participating parties can be malicious (threshold) and what actions they can take. Common models include:

• Honest Majority: Security holds if a majority of parties (e.g., >50%) are honest.
• Malicious Security: Protocols remain secure even if parties deviate arbitrarily from the protocol, requiring more complex zero-knowledge proofs.
• Semi-Honest (Passive) Security: Assumes parties follow the protocol but may try to learn extra information from transcripts; this is weaker but more efficient. The chosen model directly impacts protocol complexity, communication overhead, and real-world applicability.

MPC's primary limitation is its significant communication complexity. To compute a function without a trusted party, participants must exchange many cryptographic messages, creating bottlenecks.

• Round Complexity: The number of sequential communication rounds can delay results, especially with high network latency.
• Bandwidth Requirements: Transmitting secret shares and proofs, particularly in malicious security models, consumes substantial bandwidth.
• Computational Cost: Cryptographic operations like oblivious transfers and zero-knowledge proofs are computationally intensive, limiting throughput for complex computations like training large machine learning models.

MPC guarantees the process is private, but the final output itself can reveal information about the private inputs, a fundamental limitation known as output privacy.

• Function Design: The computed function f(x,y) must be carefully chosen. Computing max(x,y) reveals which party had the larger value.
• Auxiliary Information: An adversary with external knowledge (auxiliary input) can combine the output with that data to infer private inputs.
• Selective Failure Attacks: A malicious party can craft invalid inputs to cause the protocol to fail in a way that leaks information about an honest party's secret.

Many MPC protocols require a trusted setup phase to generate correlated randomness or cryptographic parameters, which becomes a single point of failure if compromised.

• Trusted Dealer: Some schemes need a dealer to distribute initial secret shares; the dealer must be trusted and then securely eliminated.
• Key Generation: For threshold signatures, the distributed key generation (DKG) process itself must be secure against malicious participants attempting to bias the resulting key.
• Long-Term Secrets: While private keys are never assembled, the secret shares held by each party are long-lived credentials that must be stored with equivalent security to a private key.

The theoretical security of MPC can be undermined by flawed implementations vulnerable to side-channel attacks.

• Timing Attacks: Variations in computation time can leak information about secret data paths.
• Memory Access Patterns: Even on encrypted data, access patterns to memory (cache attacks) can reveal sensitive information.
• Protocol-Specific Bugs: Complex, stateful protocols are prone to subtle implementation bugs that break security guarantees. This necessitates extensive auditing and the use of formally verified frameworks.

A significant limitation in many MPC protocols is the inability to guarantee fairness or guaranteed output delivery.

• Early Abort: A malicious party can halt the protocol after learning the output but before the honest parties receive it. This is critical in financial applications (e.g., "I get the answer, you get nothing").
• Fair Exchange: Achieving true fairness where either all parties get the output or none do requires additional rounds and assumptions, often increasing overhead.
• Robustness: Protocols with robustness guarantee output delivery regardless of malicious behavior, but they are less efficient and often require a higher honest majority threshold.

A wallet technology that requires multiple private keys to authorize a transaction. Unlike MPC-based TSS, traditional multisig uses multiple distinct blockchain addresses and signatures on-chain. Key differences:

• MPC/TSS: A single, shared public address with distributed signing logic.
• Multisig: Multiple public addresses, with all signatures visible on-chain. MPC wallets generally offer better privacy, efficiency, and flexibility than on-chain multisig.