There's a lot of hype around MPC.[^1] People say, _It's the future of finance! It's the gold standard for security!_ And while we think MPC is pretty awesome—we even work on it academically—there's a difference between admiring a technology and believing in it with religious fervor. This blog aims to separate the faith from the fact by examining what MPC gives you and what it doesn't.<br> <br> We don't have to go much further than the definition to see why people are so excited about MPC. An "MPC wallet” uses multi-party computation to sign transactions, and each "party” participating in the wallet's MPC protocol has a piece of the private key (their "share” or "shard”). Some "threshold” number of parties (e.g., three out of five) can jointly produce a signature without revealing their shares or the key to one another—or, ideally, to attackers. This means that as long as enough parties remain uncorrupted, an MPC wallet is secure—it is impossible to extract the secret key.<br> <br> This theoretical property is the reason that people build wallets on top of MPC protocols—and sadly, it's become a bit of a meme. You'll hear two particularly common refrains: _In MPC, there's no single point of failure!_ And: _the key only exists as shards!_ But reducing precise cryptographic properties to aspirational marketing slogans is reminiscent of digestion: wholesome inputs are processed into... something else.<br> <br> ## Marketing Claim #1: There's no single point of failure (so attacks are really tough)<br> <br> If each party's software is different, deployed with different cloud infrastructure, and deployed using a different administrator account, Marketing Claim #1 may be true! In practice, though, almost all wallets execute identical software for each party in the protocol—and many run that software on a set of virtually identical computers. When _no single point of failure_ actually means _a few identical points of failure_, an attacker capable of corrupting one party can trivially corrupt _every_ party. <br> <br> <br> Even if you execute a party on your phone or <a href="/blog/why-you-should-never-handle-private-keys-in-the-browser" target="_blank">browser</a>, you run into a related problem: where did that code come from? In most systems, the answer is _it came from the same vendor who's running the other parties in the protocol_—so in practice that vendor is _still_ a single point of failure.<br> <br> Wallet builders have yet another opportunity to introduce a single point of failure by misunderstanding their <a href="/blog/threat-modeling-for-web3-key-management" target="_blank">threat model</a>. There are many different flavors of MPC, and several offer better performance at the cost of worse security. <a href="https://www.verichains.io/tsshock/" target="_blank">Multiple recent security advisories</a> concern wallets that, in effect, chose an "honest-but-curious” MPC protocol—a flavor that's broken by any party who decides to deviate from the protocol. The result was that _every_ party was a single point of failure.<br> <br> ## Marketing Claim #2: The key never really exists (so it's impossible to steal)<br> <br> To unpack Marketing Claim #2, we have to start by understanding how to implement an MPC-based wallet. The wallet's core algorithm is a digital signature scheme like Secp256k1 or Ed25519, and turning that algorithm into a multi-party computation requires an astonishingly complex transformation: each step in the signing procedure—a simple arithmetic operation, say—becomes its own cryptographic protocol involving network communication and, frequently, a zero-knowledge proof from each party.<br> <br> The resulting protocol is orders of magnitude more complex than the original signature scheme, and the resulting _implementation_ is more tortured still—and any error almost certainly breaks security. <a href="https://www.fireblocks.com/blog/gg18-and-gg20-paillier-key-vulnerability-technical-report" target="_blank">MPC protocols</a> and <a href="https://www.coinbase.com/blog/the-subtleties-of-error-handling-flaws-in-mpc" target="_blank">their implementations</a> have been broken before—and they will be again and again—until we can prove them correct. The current approach to proving protocols correct means tens of pages of dense, hand-checked, <a href="https://link.springer.com/chapter/10.1007/978-3-031-15802-5_23" target="_blank">buggy math</a> ; eliminating bugs in these proofs by machine checking them requires new research innovations; and formally verifying protocol _implementations_ will require more than a pinch of divine inspiration.<br> <br> Finally, even if the protocol is correct, there's another hurdle: almost every existing MPC wallet materializes secret keys at least once in their lifetime, at key generation. Most wallets generate keys _before_ splitting them into shares, because MPC protocols for key generation (or "distributed key generation protocols”) are expensive and complex.<br> <br> ## The Dirty Secret: Performance is a problem (so people sacrifice security)<br> <br> You've probably noticed a theme: many real MPC systems fail to meet their theoretical promise because they sacrifice security for performance. This isn't a coincidence. In an MPC protocol, many parties (connected over a network) run a joint computation without revealing their private inputs (thanks to expensive cryptography). Both the _network_ and the eponymous _expensive cryptography_ are, well, very expensive—and they're both fundamental to protocol implementations (at least, the ones that don't cut corners). MPC wallets need heavyweight crypto and network traffic, so many legitimate implementations take something like ten seconds to produce a signature.<br> <br> Ten second latencies aren't something that traders, gamers, or really anyone who's used the normal web will put up with; we've talked to traders who use popular MPC wallets _with the MPC turned off_. That's just a hot wallet with a pricey brand name.<br> <pre> <br> <br> </pre> [^1]: In Web3, MPC tends to be conflated with threshold signature schemes. MPC is actually much broader than just signatures: it can be used to execute arbitrary computations! In this blog post, though, we'll use MPC colloquially to mean multiple parties collaborating to produce a signature.<br> <br>