Two cryptographic tools keep showing up in the same sentence this year, and most explanations still muddle them together. Zero-knowledge proofs let one party convince another that a statement is true without handing over the underlying secret. Secure multi-party computation lets several parties jointly compute a result over data they never fully share with each other. Both hide information. Neither works the same way, and picking the wrong one for a production system costs real money in gas fees, latency, or worse, a security hole.
The confusion is understandable. Coinbase’s own open-source MPC library, cb-mpc, uses zero-knowledge proofs as internal building blocks for its threshold-signature protocols. That is not a contradiction. It is the clearest sign that these two techniques are not rivals fighting for the same job, they are different tools that sometimes work together on the same crew. This piece breaks down what each one actually does, where each has shipped in production in 2026, what the benchmarks say, and which one a team should reach for depending on the problem in front of them.
What Is a Zero-Knowledge Proof, Exactly?
NIST’s Privacy-Enhancing Cryptography project defines a zero-knowledge proof as a way to prove knowledge of a secret solution to a problem without revealing the solution itself. One party, the prover, holds a secret (a private key, a password, an age, a credit score). The other party, the verifier, wants to confirm a specific claim about that secret is true. The proof convinces the verifier without ever exposing the secret in transit.
Two families dominate production deployments today. zk-SNARKs (Succinct Non-interactive Arguments of Knowledge) produce small proofs that verify fast, but most constructions need a trusted setup ceremony, a one-time event where the parameters get generated and then must be destroyed. If someone keeps a copy of those parameters, they can forge proofs. zk-STARKs (Scalable Transparent Arguments of Knowledge) skip the trusted setup entirely and rely only on hash functions, which also makes them resistant to quantum attacks. The tradeoff is size: STARK proofs run much larger than SNARK proofs.
A December 2025 comparative study (arXiv:2512.10020) measured both on identical hardware, an Apple M1 chip, and the gap is stark in both directions. SNARK proof generation took 55.47 milliseconds against 3,809.64 milliseconds for STARK, making SNARK roughly 68 times faster to generate on that test circuit. Proof size ran 384 bytes for SNARK versus 68.6 KB for STARK, a difference of nearly two orders of magnitude. But verification flipped the result: SNARK verification took 1,807.42 milliseconds compared to 472.25 milliseconds for STARK, so STARK verified close to four times faster in that same test. No single system wins across every metric, which is exactly why picking between them depends on what a given application actually needs to optimize.
What Is Secure Multi-Party Computation?
MPC solves a different problem. Instead of one party proving a fact to another, MPC lets several parties who each hold a piece of private data jointly compute a function over their combined inputs, without any single party ever seeing anyone else’s raw data. Coinbase describes it plainly in its own engineering blog: MPC allows multiple parties to collectively perform computations on private data without ever exposing the underlying data itself.
In practice, most commercial “MPC” products are narrower than the general academic definition. What Fireblocks and Coinbase ship for crypto custody is closer to threshold cryptography, a specialized subset of MPC focused on one operation: splitting a private signing key into shares distributed across multiple parties or devices, so no single machine ever holds the complete key. A signature only gets produced when a threshold number of those shares cooperate. General-purpose MPC, by contrast, can evaluate arbitrary functions, private auctions, statistical queries, or machine-learning inference, over data nobody fully discloses.
NIST has been formalizing this distinction through its Multi-Party Threshold Cryptography project. The second public draft of NIST IR 8214C, “First Call for Multi-Party Threshold Schemes,” went out on March 27, 2025, and it explicitly lists zero-knowledge proofs of knowledge (ZKPoK) as one of the primitive categories (S6) that threshold schemes can call on. That single detail sums up the real relationship between these two technologies better than any marketing page: ZKPs are often a component inside MPC systems, not a competing product.
ZKP vs MPC: The Core Technical Differences
| Dimension | Zero-Knowledge Proofs | Secure Multi-Party Computation |
|---|---|---|
| Core goal | Prove a statement is true without revealing the secret behind it | Jointly compute a function over data multiple parties never fully share |
| Number of active parties | Typically one prover, one or many verifiers | Two or more parties, all holding a share of the computation |
| Interaction pattern | Often non-interactive after setup (prove once, verify many times) | Usually interactive, multiple communication rounds between parties |
| Trust assumption | SNARKs need a trusted setup ceremony; STARKs need none | Security typically holds as long as fewer than a threshold of parties collude |
| Typical output | A compact, portable proof object | A jointly computed result or a distributed signature |
| Bandwidth pattern | Low bandwidth per verification after the proof is generated | Bandwidth scales with number of parties and protocol rounds |
| Quantum resistance | STARKs are hash-based and quantum-resistant; SNARKs generally are not | Depends on underlying primitives (Paillier, OT, secret sharing) |
| Common production use | Blockchain rollups, identity proofs, compliance attestations | Crypto custody signing, private data aggregation, secure voting |
| Standardization status | Fragmented; no single NIST/IETF general ZKP standard as of September 2026 | NIST IR 8214C second public draft published March 27, 2025 |
| Where the other technique appears inside it | ZKPs rarely embed MPC | MPC protocols like Coinbase’s cb-mpc use ZKPs internally to prove correctness of shares |
| Failure mode risk | Compromised or improperly finalized trusted setup ceremonies | Collusion above the threshold, or a compromised signing endpoint |
Performance Benchmarks: Proof Generation, Verification, and Signing Speed
Benchmark numbers for both technologies vary wildly depending on hardware, circuit complexity, and implementation, so treat any single figure as a data point rather than a universal law. Still, three independent 2025-2026 sources paint a consistent qualitative picture even where the exact milliseconds disagree.
The arXiv 2512.10020 study cited above ran the same SNARK-versus-STARK comparison across four different hardware targets: an Apple M1, a Raspberry Pi, an Ubuntu server, and a PPC64 machine. SNARK proof generation ranged from 1.051 seconds on Raspberry Pi to 3.37 seconds on the Ubuntu box. STARK proof generation on the same devices ran from 2.95 seconds to 31.04 seconds, confirming the pattern that STARKs take meaningfully longer to prove but scale better on constrained hardware. A separate peer-reviewed evaluation published on PMC found that Groth16, a widely-used SNARK construction, held proof size nearly constant at 804.7 ± 1.7 bytes and verification time steady at 0.662 ± 0.032 seconds, regardless of how complex the underlying circuit got, which is the whole point of a succinct proof system.
On the MPC side, Coinbase’s own published benchmark for its cb-mpc library reports an ECDSA threshold signing operation completing in roughly 6.1 to 6.35 milliseconds across ten iterations in an eight-round configuration. A separate technical comparison of threshold-signing protocol families found that Paillier-based approaches (the GG18, GG20, and CGGMP protocols) trade heavier per-party computation for lower communication bandwidth, while OT-based approaches (DKLs18 and DKLs19) run lighter, symmetric-key computation but push more data across the wire because of the oblivious transfer step. That tradeoff, compute versus bandwidth, is the practical decision every team building threshold-signing infrastructure has to make, and it explains why Fireblocks, Coinbase, and other custody providers have each converged on slightly different protocol choices.
Ethereum Gas Costs: What It Actually Costs to Verify a ZK Proof On-Chain
For blockchain teams, the number that matters most isn’t proving time, it’s what verification costs once the proof lands on Ethereum. A September 2026 developer benchmark guide put Groth16 on-chain verification at roughly 200,000 to 230,000 gas, with PLONK running higher at around 300,000-plus gas per verification. Raw STARK verification on Ethereum, without wrapping it in a SNARK first, commonly exceeds 1 million gas, and a December 2025 rollup-infrastructure guide cited StarkWare’s SHARP proof-aggregation batches referencing figures around 6 million gas per training run, a number engineering teams use as a reality check rather than a fixed cost.
That gap is exactly why most production ZK-rollups that use STARK proving internally still wrap the final proof in a Groth16 or PLONK verifier before submitting it to Ethereum. The prover gets the transparency and post-quantum resistance of a STARK, while the chain only pays the cheaper SNARK verification bill. MPC has no equivalent on-chain cost structure to compare against, since threshold signing typically happens off-chain before a standard signature gets submitted, which is itself one more argument in favor of MPC for custody workflows where gas costs matter.
Real-World Production Deployments in 2026
Both technologies have moved well past academic papers into infrastructure that moves real money and verifies real people. Five deployments illustrate how differently they get used.
1. Fireblocks MPC-CMP for institutional custody. Fireblocks built its proprietary MPC-CMP protocol into every wallet product it ships, including treasury management and embedded wallets. The company’s own reporting from September 24, 2026 states MPC-CMP has secured $16 trillion in digital-asset transactions with zero breaches, across more than 2,500 institutional customers and over 200 blockchains. An earlier company page from April 2026 cited $10 trillion secured across 2,400-plus organizations and 150-plus blockchains, a gap that likely reflects different measurement dates and methodologies rather than a contradiction, but both figures come directly from Fireblocks and should be read as the company’s own claims rather than independently audited totals.
2. Coinbase’s open-source cb-mpc library. Coinbase open-sourced its MPC cryptography library on March 26, 2025, supporting threshold ECDSA, Schnorr, and EdDSA signing along with distributed key generation and oblivious transfer. Coinbase’s own custody description states that complete private keys are never stored at rest or on any single machine during signing, the defining property of threshold-based MPC custody. The GitHub repository is explicit that the library is a cryptographic toolkit, not a full custody service, policy engine, or workflow on its own.
3. World ID’s zero-knowledge proof-of-personhood. World (formerly Worldcoin) uses zero-knowledge proofs to let a person verify they are a unique human, via an iris-scanning Orb device, without revealing their biometric data itself in the proof. World’s own April 16, 2026 announcement states nearly 18 million users had verified their humanness at an Orb and could use World ID for online verification, up from roughly 10.2 million in January 2025 based on separate tracking. The proof lets a website confirm “this is a unique human” without ever learning which human.
4. ZK-rollups scaling Ethereum. zkSync Era, Linea, and Scroll each use zero-knowledge proofs to bundle thousands of transactions into a single proof submitted to Ethereum. A September 17, 2026 comparison citing L2BEAT-tracked data put zkSync Era at approximately $4.1 billion in total value locked with an average of 28 transactions per second, Linea at roughly $3.4 billion TVL and 22 TPS, and Scroll at about $2.1 billion TVL and 14 TPS. Reported figures for these networks have varied significantly across different snapshots and sources throughout 2026, underscoring how fast this segment of the market moves and how much TVL figures depend on the exact measurement date.
5. Threshold signing inside a single MPC library. The most technically interesting deployment might be the least visible one: Coinbase’s cb-mpc explicitly bundles zero-knowledge proofs as a supporting primitive inside its threshold-signature protocols, using ZKPs to let one party prove it correctly generated its share of a distributed key without revealing the share itself. That is ZKP and MPC working inside the same system, not competing for the same job.
Pricing and Cost Comparison
Neither technology has a simple per-unit sticker price the way a cloud API does. Costs show up differently depending on where the computation happens and who is paying for it.
| Cost Factor | Zero-Knowledge Proofs | Secure Multi-Party Computation |
|---|---|---|
| Where the cost lands | On-chain gas for verification, off-chain compute for proof generation | Off-chain compute and network bandwidth between parties |
| Groth16 on-chain verification | ~200,000-230,000 gas per proof | Not applicable |
| PLONK on-chain verification | ~300,000+ gas per proof | Not applicable |
| Raw STARK on-chain verification | Commonly exceeds 1 million gas | Not applicable |
| Typical MPC signing operation | Not applicable | ~6.1-6.35 ms compute per signature (Coinbase cb-mpc benchmark) |
| Infrastructure model | Prover hardware (often GPU-accelerated) plus on-chain fees | Distributed servers or devices per party, no blockchain fee required |
| Open-source options | Circom, SnarkJS, Winterfell (STARK), many proving frameworks | Coinbase cb-mpc (open-sourced March 26, 2025), various academic MPC frameworks |
| Commercial custody pricing | Not typically sold as a custody product | Fireblocks and similar vendors charge enterprise licensing, not disclosed publicly per transaction |
The practical takeaway: if a team is building something that needs to settle on a public blockchain, ZKP costs are dominated by gas, and the SNARK-versus-STARK-versus-wrapped-STARK decision directly moves that number. If a team is building custody or private computation infrastructure that never needs to touch a blockchain’s verification layer, MPC’s costs are almost entirely about server infrastructure and network latency between the parties holding key shares.
Developer Tooling: What Building With Each Actually Looks Like
The two ecosystems have grown apart in how developers interact with them day to day. ZK development usually means writing a circuit in a domain-specific language, compiling it, running a setup step (for SNARKs) or skipping it (for STARKs), then generating and verifying proofs against that fixed circuit. Circom paired with SnarkJS remains a common open-source combination for Groth16 and PLONK-style SNARK circuits, while Winterfell and similar libraries handle STARK proving. A simplified circuit definition for proving knowledge of a value without revealing it looks roughly like this:
// Simplified Circom-style circuit: prove you know x such that x^2 == public_y
template SquareProof() {
signal input x; // private witness, never revealed
signal input public_y; // public input, known to the verifier
signal output valid;
component sq = Multiplier();
sq.a <== x;
sq.b <== x;
valid <== sq.out - public_y; // must equal 0 for the proof to verify
}MPC development looks structurally different because the code has to run across multiple independent parties simultaneously, coordinating over a network rather than compiling to a single static circuit. A conceptual call into a threshold-signing library, similar in spirit to Coinbase's cb-mpc interface, looks more like a distributed function call than a proof generation step:
// Simplified threshold-signing flow across 3 parties, 2-of-3 threshold
const keyShares = mpc.distributedKeyGen({ parties: 3, threshold: 2 });
// Each party independently holds one share; no party ever sees the full key
const signature = await mpc.thresholdSign({
message: txHash,
myShare: keyShares.localShare,
threshold: 2,
parties: [partyA, partyB, partyC]
});
// signature verifies against a standard public key, indistinguishable
// on-chain from a signature produced by a single-key walletThe practical difference shows up immediately in testing and deployment. A ZK circuit is deterministic and can be unit-tested against fixed inputs the same way any pure function would be. An MPC protocol has to be tested across simulated network conditions, party dropouts, and timing variance, since its correctness depends on multiple machines actually coordinating in real time rather than one process running a single computation.
Security Considerations and Known Failure Modes
Both technologies carry real, documented risks, and neither is a magic bullet against a poorly designed system built on top of it.
A September 7, 2026 security research post reported that the root cause behind incidents in two unnamed systems was not a new cryptographic break, but Groth16 verifiers generated from trusted setups that had not been finalized correctly. That distinction matters: a mathematically sound proof system can still fail in production if the ceremony that generated its parameters was mishandled. It is the single strongest argument in favor of zk-STARKs in situations where teams cannot fully trust every participant in a setup ceremony, since STARKs eliminate that step entirely by relying only on collision-resistant hashing.
MPC's failure modes tend to look different in practice. Because most commercial "MPC custody" products are really threshold-signature schemes, the security model depends on the assumption that fewer than the threshold number of key-share holders will ever collude or get compromised simultaneously. That assumption can break down through insider collusion, a compromised signing endpoint, or an authorization-policy bug sitting on top of otherwise sound cryptography, none of which is a flaw in the MPC math itself. Distinguishing between "the cryptography failed" and "the surrounding system failed" is essential when evaluating any custody provider's security track record, including the zero-breach claims vendors like Fireblocks publish about their own MPC-CMP protocol.
Use Cases: When to Choose Zero-Knowledge Proofs
- Blockchain scaling (rollups): When thousands of transactions need to be bundled into one proof that a single chain can verify cheaply, ZK-rollups like zkSync Era, Linea, and Scroll are the established pattern.
- Proof-of-personhood and identity: When a system needs to confirm "this is a real, unique human" or "this person is over 18" without learning who the person is, ZKPs are purpose-built for exactly that, as World ID demonstrates at scale.
- Compliance attestations: When an auditor or regulator needs proof that a company followed a rule (reserves match liabilities, a transaction stayed under a threshold) without seeing the underlying ledger, a succinct proof avoids exposing sensitive business data.
- One-to-many verification: Any time a single proof needs to be checked repeatedly by many independent verifiers, the succinctness of SNARKs or the transparency of STARKs pays off, since the expensive proving step happens once.
- Post-quantum-sensitive systems: Where long-term data confidentiality against future quantum attacks matters, zk-STARKs' hash-based construction is the safer starting point over SNARK constructions that typically rely on pairing-based elliptic curve assumptions.
Use Cases: When to Choose Multi-Party Computation
- Institutional crypto custody: When no single device or employee should ever hold a complete private key, threshold-signature MPC is the standard approach, as Fireblocks and Coinbase have both built their custody stacks around it.
- Joint computation across mutually distrusting parties: When two or more organizations need to compute something together (a shared statistic, a joint risk score) without either side seeing the other's raw dataset, general-purpose MPC is the direct fit, since that is precisely the problem it was designed to solve.
- Distributed key generation: When a signing key needs to be generated collaboratively so that no single party ever possesses the full key, even momentarily, MPC's distributed key generation protocols (as used in Coinbase's cb-mpc) handle this natively.
- Low-latency signing infrastructure: For operations that need to happen repeatedly and fast, such as high-frequency institutional signing, MPC benchmarks in the single-digit millisecond range (per Coinbase's published cb-mpc results) beat the seconds-scale proving times common to ZK-SNARK and STARK generation.
- Private auctions and voting: When multiple parties need a jointly-computed outcome (an auction winner, a vote tally) without any party learning individual inputs, MPC protocols built for secure aggregation are the established academic and increasingly commercial solution.
Migration Guide: Moving From a Trusted-Third-Party Model to ZKP or MPC
Teams migrating away from a centralized trust model, a single custodian holding a full key, or a single server verifying a fact by seeing the raw data, tend to follow a similar path regardless of which technology they land on.
- Step 1: Map the actual trust problem. Decide whether the goal is "prove a fact without revealing the secret" (points toward ZKP) or "compute jointly without sharing raw inputs" (points toward MPC). These are different questions, and conflating them early leads teams to bolt on the wrong primitive later.
- Step 2: Inventory where the current single point of trust lives. For a custody migration, that's usually one machine or one employee holding a full private key. For a data-sharing migration, it's usually one central server that sees everyone's raw inputs.
- Step 3: For ZKP migrations, choose SNARK or STARK based on setup trust, not just speed. If the team can run a credible, auditable trusted-setup ceremony and needs the smallest possible proofs and cheapest gas, SNARK constructions like Groth16 remain the default for on-chain verification. If setup trust is a hard blocker, or the system will still need to be secure decades from now against quantum attacks, STARKs remove that dependency entirely.
- Step 4: For MPC migrations, choose a threshold scheme and pick t-of-n carefully. A 2-of-3 threshold is common for custody, balancing availability (losing one share doesn't lock funds) against security (a single compromised share can't sign alone). Evaluate whether a Paillier-based protocol (lower bandwidth, heavier per-party compute) or an OT-based protocol (lighter compute, higher bandwidth) fits the team's infrastructure constraints.
- Step 5: Run a shadow period before cutover. Keep the legacy trusted-party system live and verify the new ZKP or MPC system's outputs against it before fully switching signing or verification authority over.
- Step 6: Plan for key or witness rotation from day one. MPC key-share refresh protocols and ZKP circuit upgrades both need a defined process, since neither technology automatically handles the case where a party's device is later suspected of compromise.
- Step 7: Budget for audits specific to the primitive chosen. A ZKP system needs its circuit logic and, if applicable, its trusted-setup ceremony audited. An MPC system needs its threshold protocol implementation and its surrounding authorization policy (who can request a signature, under what conditions) audited separately, since that policy layer sits outside the cryptography itself.
Pros and Cons: Zero-Knowledge Proofs
Pros: Proofs can be verified by unlimited parties once generated, ideal for public blockchains. STARKs need no trusted setup and are quantum-resistant. Proof generation happens off-chain, keeping on-chain costs to just verification. Mature tooling exists (Circom, SnarkJS, Winterfell) with years of production hardening from rollup teams.
Cons: SNARK trusted-setup ceremonies introduce a real, documented failure mode if mishandled, as the September 2026 zkSecurity research on improperly finalized setups shows. STARK proofs run tens of kilobytes larger than SNARK proofs, increasing storage and bandwidth. On-chain verification gas costs, while lower than raw computation would be, still add up at scale, pushing many rollups toward SNARK-wrapped STARKs as a compromise. Circuit design mistakes are a persistent, hard-to-audit source of bugs.
Pros and Cons: Multi-Party Computation
Pros: No single point of failure for key custody, since no complete key ever exists on one machine. Signing latency runs in the single-digit-millisecond range per Coinbase's published benchmarks, far faster than ZK proof generation. General-purpose MPC can compute arbitrary functions, not just prove a single statement. No blockchain gas costs, since computation happens entirely off-chain.
Cons: Requires active, multi-round communication between parties, which introduces latency and bandwidth overhead that scales with the number of participants. Security depends on an assumption about how many parties can collude, which is a policy and operational question as much as a cryptographic one. Most commercial "MPC" products are narrower threshold-signature schemes rather than fully general MPC, which can create a mismatch between marketing claims and what the system actually does. Standardization is still in draft form, with NIST IR 8214C at second public draft as of March 2025.
The Verdict: Which One Should You Actually Use?
There isn't a single winner, because these two technologies answer different questions. If the problem is "prove this fact to anyone who asks, without revealing the secret," zero-knowledge proofs are the right tool, and the SNARK-versus-STARK choice comes down to whether a trusted setup is acceptable and whether smaller proofs or faster verification matters more for the specific use case. World ID's nearly 18 million verified humans and the tens of billions of dollars locked in zkSync, Linea, and Scroll rollups show this pattern working at real scale in 2026.
If the problem is "let multiple parties jointly hold or compute something without any single party seeing the whole picture," MPC, or more precisely, the threshold-cryptography subset of it that vendors actually ship, is the right tool. Fireblocks' claimed $16 trillion in MPC-secured transaction volume and Coinbase's open-sourced cb-mpc library both point to the same conclusion: for custody and joint signing, MPC has become the default, not an experimental alternative.
And for teams building anything sophisticated, the real answer is often both at once. Coinbase's own architecture proves that ZKPs and MPC aren't mutually exclusive design choices, they're complementary layers, with zero-knowledge proofs verifying the correctness of shares inside an MPC protocol. Understanding that these tools stack rather than compete is the single most useful thing a team can take away before starting either kind of migration.
Frequently Asked Questions
Is a zero-knowledge proof the same thing as encryption?
No. Encryption hides data so only someone with the right key can read it. A zero-knowledge proof proves a fact about hidden data without ever revealing the data itself, even to the verifier. A system can use both together, encrypting data at rest while using a ZKP to prove something about that data without decrypting it.
Can MPC and zero-knowledge proofs be used in the same system?
Yes, and it happens in production today. Coinbase's cb-mpc library uses zero-knowledge proofs internally so parties in a threshold-signing protocol can prove they generated their key share correctly, without revealing the share itself.
Which is faster, zk-SNARKs or zk-STARKs?
It depends on which step. A December 2025 study found SNARKs generated proofs roughly 68 times faster than STARKs on the same hardware, but STARKs verified about 3.8 times faster in that same test. SNARK proofs were also nearly 180 times smaller. Neither wins on every metric.
Do zk-SNARKs require a trusted setup?
Most zk-SNARK constructions, including Groth16, require a one-time trusted setup ceremony to generate proving and verification parameters. If the ceremony's secret randomness isn't fully destroyed, whoever kept it could forge proofs. zk-STARKs avoid this requirement entirely by relying only on hash functions.
Is MPC the same as a multisig wallet?
They solve a similar problem differently. A multisig wallet uses on-chain smart-contract logic requiring multiple separate signatures to approve a transaction, visible on the blockchain as multiple distinct signing events. MPC threshold signing produces a single, standard-looking signature off-chain, generated jointly by multiple key-share holders, so the blockchain never sees that multiple parties were involved.
How much does it cost to verify a ZK proof on Ethereum?
Per a September 2026 developer benchmark, Groth16 verification runs roughly 200,000 to 230,000 gas, PLONK runs around 300,000-plus gas, and raw STARK verification commonly exceeds 1 million gas unless wrapped in a cheaper SNARK verifier first.
Is NIST standardizing either of these technologies?
NIST is further along with threshold cryptography and MPC, having published the second public draft of NIST IR 8214C, "First Call for Multi-Party Threshold Schemes," on March 27, 2025. There is no equivalent finalized, general-purpose NIST or IETF standard for zero-knowledge proofs as of September 2026, though individual components like specific curves and commitment schemes have their own standards.
Which one should a startup building a crypto wallet use?
For wallet custody specifically, MPC (in practice, threshold signing) is the established path, used by Fireblocks, Coinbase, and most institutional custody providers, because it eliminates the single-point-of-failure risk of one device holding a complete private key. Zero-knowledge proofs become relevant if the wallet also needs to interact with ZK-rollups or prove compliance facts without exposing transaction history.
Does either technology protect against a quantum computer?
Only partially, and it depends on the specific construction. zk-STARKs rely solely on hash functions, which are considered quantum-resistant, so they hold up better than SNARK constructions that typically depend on elliptic-curve pairings, a category of math that quantum computers are expected to eventually break. MPC's quantum resistance depends entirely on the underlying signature scheme being secured, threshold ECDSA and EdDSA are just as exposed to a future quantum attack as their non-threshold counterparts, since the threshold layer protects key custody, not the underlying signature math.
How many parties does an MPC protocol typically need?
It varies by design, but custody-focused threshold schemes commonly use configurations like 2-of-2 or 2-of-3, where a majority or all of a small set of key-share holders must cooperate to produce a valid signature. General-purpose MPC used for private data computation can involve many more parties, since the goal there is joint computation across organizations rather than distributed control of a single signing key.
