Multi-Party Computation (MPC): Threshold Signatures and Private Compute

1) Concepts: Secret Sharing and Threshold Signing

Secret sharing splits a secret into parts so that any t of n parts can reconstruct the secret, while fewer than t reveal nothing. The most common building blocks are:

• Shamir Secret Sharing (SSS): encodes the secret as the constant term of a random polynomial. Each share is a point on that polynomial. Reconstruction uses Lagrange interpolation. This is great for backup and recovery but does not by itself let you sign without reconstructing.
• Distributed Key Generation (DKG): parties jointly create a public key and local shares without ever assembling the full private key anywhere. Each party proves its contribution is consistent. DKG prevents a dangerous “one moment in RAM” where the key exists in whole.

Threshold signatures (TSS) adapt signature schemes so a group can produce one standard signature without reconstructing the key. The chain sees a normal signature; the threshold magic stayed off chain.

• Threshold ECDSA: the default for Ethereum and many EVM chains. Parties cooperatively create a nonce and partial signatures that combine into a standard ECDSA signature.
• Threshold EdDSA / Schnorr: common in ecosystems that use Ed25519 or Schnorr. Protocols can be simpler, and some support highly efficient two round signing.
• Threshold BLS: useful for committees, aggregators, and oracles. BLS supports compact aggregation, but it also invites rogue key pitfalls if you do not include proofs of possession.

Takeaway: TSS preserves on-chain simplicity and wallet compatibility. The trade is that your policy and assurance live off chain, so you must design and document them like any other critical system.

2) TSS versus Multisig and Smart Accounts

Rule of thumb: prefer TSS when EOA compatibility, cross-chain uniformity, or private policy is paramount (for example, institutional custody, market maker hot wallets). Prefer multisig or smart accounts when public, enforceable on-chain policy matters (for example DAO treasuries, upgrade admins).

3) What Actually Happens During a Threshold Signature

Every TSS flavor follows the same rhythm: commit to randomness, exchange commitments, derive a joint nonce and context, produce partial signatures, then combine them into a single signature.

// Example: 2-of-3 threshold ECDSA (conceptual)

// One-time setup
A, B, C run DKG → shares sA, sB, sC; publish public key PK

// To sign message digest m with A and B:
1) A and B sample nonce shares (kA, kB) and commit to them
2) Exchange commitments; reveal nonces; derive R = kA*G + kB*G
3) Compute challenge e = H(Rx || PK || m)
4) Each computes partial sig:  σi = k_i + e * s_i  (mod n)   // schematic
5) Combine partials → σ = (r = Rx mod n, s = combine(σA, σB))
Verify(σ, m, PK) == true  // On chain this is an ordinary ECDSA signature

Subtleties that matter:

• Nonce hygiene: if nonces repeat or are biased, ECDSA private keys leak. Modern protocols use verifiable nonce commitments or deterministically derive nonces from fresh randomness and the message. Monitor across sessions to ensure no duplication.
• Abort and availability: any interactive protocol can be stalled by a participant. Production systems add blame (to identify which party misbehaved), retry with another signer, and escalation paths.
• Transcript privacy: do not log raw nonces, shares, or intermediate values. Logs should include opaque session ids, participant ids, timing, and the final signature hash.
• Rounds and latency: EdDSA/Schnorr often needs fewer rounds than ECDSA, which reduces latency for human approvals. BLS has different properties and requires protection against rogue key attacks.

4) DKG and Verifiable Secret Sharing (Key Generation)

DKG avoids ever creating the full private key. Each participant samples its own polynomial, distributes commitments, and proves consistency. Everyone ends with a local share that adds up (in the group) to a single public key.

• Verifiable secret sharing (VSS): commitments (for example to polynomial coefficients) let recipients check that their share is consistent with what others received. Misbehavior is either detected or attributable (complaints phase).
• Bias resistance: protocols must prevent a party from biasing the resulting public key. Use established, audited DKG variants rather than ad hoc code.
• Key refresh: proactive resharing changes each party’s share without changing the joint public key. This is powerful: you can rotate devices and providers yet keep the same on-chain address.

// DKG sketch (concept)
// Each party P_j chooses polynomial f_j of degree t-1, with secret a_j = f_j(0)
// For i in [1..n], P_j sends share s_{i,j} = f_j(i) to party i
// Everyone publishes commitments C_{j,k} to coefficients of f_j
// Party i checks sum_j (verify(s_{i,j} vs C_{j,*})) → if ok, set s_i = sum_j s_{i,j}
// Public key: PK = (sum_j a_j) * G
// Now s_i are the local shares; no one knows sum_j a_j explicitly

5) Threat Model and Failure Modes

Design around the assumption that some participants may be offline, malicious, or compromised. Typical risks:

• Nonce failures: duplicate or correlated nonces in ECDSA leak keys. Use verifiable nonce generation, independent randomness sources, and monitoring that raises an alert if the same nonce appears twice for a key.
• Coordinator compromise: if a single coordinator controls message ordering and participation, it can attempt bias or denial. Use authenticated broadcast, multiple coordinators, or at least immutable transcripts and audit trails.
• Collusion: an attacker who compromises t or more shares can sign. Choose t and n to match your threat model and split across truly independent control domains (different clouds, teams, and vendors).
• Rogue key attacks (BLS): without proofs of possession a participant can craft a key that cancels another’s contribution. Always require proofs of possession for BLS committees.
• Denial of service: a malicious signer can stall signatures. Have a playbook to remove and replace signers, and an emergency path using a higher threshold wallet or a recovery provider.
• Policy bypass: if approvals live off chain, ensure every signing request flows through a risk engine and a human-in-the-loop or automated approval consistent with policy. Signing microservices should refuse ad hoc calls.
• Share leakage: backups or logs that accidentally contain shares are a latent risk. Classify, encrypt, and track access to any artifact that could become a share or a seed.

6) Wallets, Custody, and Key Ceremonies

MPC wallets for teams. A common split is 2-of-3 across:

• Cloud HSM service (operator controlled, audited).
• On-prem hardware (finance or security team controls it physically).
• Recovery provider or a locked down mobile device held by an executive sponsor.

Benefits: a lost device or compromised cloud account does not lose funds; rotation simply reissues the affected share without changing the address.

Institutional custody. Larger organizations add separation of duties and human checkpoints:

• Pre-trade risk checks (address allowlists, chain allowlists, velocity caps).
• Dual control (two teams approve before the signing round can even start).
• Time-of-day windows and geofencing on signer devices.
• Out-of-band confirmations for large withdrawals (voice callback or an enterprise identity challenge).

Key ceremonies. Treat initial DKG and every resharing as a formal ceremony:

1. Define roles (ceremony lead, security observer, recorder, participants).
2. Derive entropy from multiple sources; record checksums of randomness beacons.
3. Run DKG with verifiable transcripts; store artifacts in sealed, tamper-evident storage.
4. Test a “signing smoke test” and a “share loss drill” before declaring the key live.

7) Private Compute with MPC (Beyond Signing)

MPC can compute on private data, not just sign. Three practical categories:

• Private set operations: private set intersection allows two institutions to find overlapping customers without sharing full lists. Useful for Travel-Rule counterparty discovery and fraud-ring detection.
• Analytics and model inference: secret-sharing based MPC evaluates linear algebra on encrypted shares. This supports risk scoring or anti-abuse models across organizations with privacy.
• Auctions and matching: sealed-bid auctions where bids remain hidden until the protocol reveals the outcome (winner and clearing price) without revealing losing bids.

MPC + ZK pattern: compute off chain with MPC, then produce a zero-knowledge proof that the revealed output is consistent with committed inputs and the algorithm. Contracts verify the proof without learning sensitive data.

8) Design Choices and Implementation Notes

• Choose signature family by chain: ECDSA for EVM chains, EdDSA or Schnorr for ecosystems like Solana or Bitcoin variants, BLS for committees and aggregations.
• Use DKG rather than split-after: avoid any moment when the full private key exists.
• Share placement: distribute across different vendors, geographies, and organizational owners. Never place two shares on the same logical machine or in the same admin boundary.
• Proactive resharing cadence: schedule resharing after personnel changes and at fixed intervals (for example quarterly). Ensure the protocol keeps the same public key to avoid changing addresses.
• Approval hooks: make the signing coordinator call out to a risk engine before starting a round. If the call fails or the policy denies, abort before any cryptography starts.
• Transport security and identity: mutually authenticate all signer nodes with short lived certificates and device attestation when possible. Pin identities of peer signers.
• Time and randomness: signer nodes should have secure time sources and hardware entropy. Combine entropy from multiple devices and from the message being signed to derive nonces.
• Audit trail: write tamper-evident logs that capture who approved, which policy triggered, session ids, and a hash of the final signature. Do not log secrets or nonces.
• Testing: fuzz the coordinator with malformed messages, simulate signer dropouts, and run chaos drills that randomly kill one signer in the middle of rounds.

// Pre-sign policy gate (pseudo-logic)
function preflight(tx) {
  require(allowlistedChain[tx.chainId], "blocked chain");
  require(allowlist[tx.to], "unknown destination");
  require(tx.value <= dailyLimit[tx.asset], "over limit");
  require(priceAge(tx.asset) <= 60, "stale price");
  // Record intent → route to human approvals if over threshold
  emit IntentLogged(tx.hash, msg.sender, now());
}

9) Combining MPC with Account Abstraction

Account abstraction adds programmable rules to transactions: session keys, sponsored gas, and policy modules. MPC can serve as the signing backbone while smart-account logic enforces rules on chain.

• Session keys: issue short-lived keys for bots and market makers with strict scopes (token, spend cap, function list). Revoke without touching MPC shares.
• Paymasters: sponsor gas for user flows while still requiring MPC approval for high risk actions.
• Hybrid custody: user transactions flow through a session key path; treasury and upgrades require MPC-backed approvals and possibly a higher threshold or delay module.

10) Performance and Latency Budgets

Interactive rounds add latency. Plan targets and measure:

• Human-in-the-loop approvals: often dominate latency (tens of seconds to minutes). Make approval notices real time and include simulation screenshots and destination tags to reduce hesitation.
• Network round trips: threshold ECDSA may require multiple network exchanges; EdDSA can often complete in fewer rounds. Place signer nodes in low-latency regions and prefer private, authenticated links.
• Throughput: batch small transfers with a single approval when policy allows. For high frequency trading, consider session keys scoped to specific contracts while keeping MPC for high value moves.

Practical tip: build a dashboard that shows queue depth, median and p95 signing time, and failure reasons (policy reject, signer offline, nonce mismatch).

11) Operations: Audits, Logging, Disaster Recovery

• Audits: get both the cryptographic protocol implementation and the surrounding approval and logging code audited. Many real incidents are not crypto bugs but policy bypasses.
• Immutable logs: export logs to write-once storage with regular checkpoint hashes. Consider submitting log hashes to an on-chain registry for extra integrity.
• Runbooks: document signer removal, resharing, and how to operate during cloud outages. Practice quarterly.
• Break-glass: define a stricter, slower path for emergencies: a higher threshold wallet or a pause control that requires more signers and a deliberate delay.
• Key custody statements: publish a short controls document: where shares live, who approves, how you monitor, and how customers can verify a transaction was policy compliant.

12) Vendor Selection and RFP Checklist

Questions to ask when evaluating an MPC wallet or custody provider:

• Protocol details: which TSS variant and DKG do they implement? Is the code public or audited? How do they guarantee nonce safety?
• Separation of duties: can you hold a share yourself on hardware you control? Can another independent provider hold the recovery share?
• Policy engine: how are allowlists, limits, and approvals enforced? Is there an API to assert policy decisions inside your systems?
• Observability: what logs and webhooks exist? Can you export signing transcripts (redacted) and approval trails for compliance?
• Resharing and rotation: how quickly can you replace a device? Does resharing preserve the public key so addresses do not change?
• Latency and SLA: typical p50 and p95 signing time, region coverage, and disaster recovery commitments.
• Incident history: how are incidents disclosed? Are there public post-mortems?

13) API Patterns: How Apps Call an MPC Signer

Most integrations follow a “request → approve → sign” pipeline:

1. Request: app submits a transaction intent (to, value, calldata, chain id, simulation result). The coordinator returns a request id.
2. Risk check: the engine evaluates policy (limits, allowlists, analytics). If the request fails, the pipeline aborts with a reason.
3. Human approval: if required, approvers receive a signed summary (domain, chain id, decoded calldata) and approve in their app.
4. Signing: the coordinator starts the TSS rounds and returns a standard signature. The app submits to the chain.

// EIP-712 typed data for approval (concept)
domain = { name: "Treasury MPC", version: "1", chainId, verifyingContract }
types = {
  Intent: [
    {name:"to", type:"address"},
    {name:"value", type:"uint256"},
    {name:"calldataHash", type:"bytes32"},
    {name:"nonce", type:"uint256"},
    {name:"expiresAt", type:"uint64"}
  ]
}
message = { to, value, calldataHash, nonce, expiresAt }
signature = userSigner._signTypedData(domain, types, message)
// MPC coordinator verifies this user approval before starting TSS

14) FAQ

Q: On chain, how can someone tell I used MPC?
A: They cannot. A TSS signature verifies to your public key like any other EOA signature. The MPC policy is off chain.

Q: Does MPC replace multisig?
A: Not universally. MPC gives EOA compatibility and silent policy; multisig gives transparent, enforceable on-chain policy. Many teams use both: MPC for daily operations and a multisig or timelocked smart account as an owner or guardian.

Q: Can I rotate devices without changing addresses?
A: Yes, with proactive resharing you can replace a device or provider while keeping the same public key and address.

Q: What is the biggest real-world risk?
A: Nonce misuse in ECDSA and gaps in off-chain policy enforcement. Address both with verifiable nonces, independent randomness, rigorous approvals, and immutable logs.

Q: Do I need hardware?
A: Strongly recommended. Host at least one share in a hardware security module or secure enclave and protect others with device attestation and strict access controls.

Quick check

1. On chain, what is the visible difference between a TSS-based wallet and a multisig wallet?
2. Why is nonce handling critical in threshold ECDSA, and how do robust protocols mitigate the risk?
3. Give one Web3 use case for general MPC that is not about signatures.
4. What is proactive resharing and why is it useful?
5. Name two questions you would ask an MPC vendor about their implementation.

Go deeper

• Concepts: distributed key generation and verifiable secret sharing, threshold ECDSA and EdDSA, threshold BLS and proofs of possession, proactive secret sharing.
• Operations lectures: ceremony playbooks, segregation of duties, signer attestation, immutable logging, resharing drills.
• Architecture lectures: MPC combined with account abstraction, layered policy stacks (risk engine and on-chain limits), MPC plus zero-knowledge proofs for verifiable private compute.
• Security lectures: nonce failure case studies, rogue key defenses for BLS, coordinator minimization, incident communications and recovery from compromised shares.

Next: Homomorphic Encryption — compute on encrypted data and prove it on chain.

Next: Homomorphic Encryption →