# Multiparty Computation: Collaborative Execution Without Centralized Machines
## Alternative titles
- What MPC is as a computing model
- What MPC is as a backend architecture
- The End of the Data Custodian: Building Apps That Can’t See Their Own Data
- MPC: Programming Without the Liability of Data Storage
- Designing for Zero-Trust: The Architect’s Case for Multiparty Computation
- What You Don't Know Can't Leak: The Magic of MPC
- The Cloud is a Liability—MPC is the Solution
- Collaborative Execution: Scaling Distributed Compute with MPC
- Multiparty Computation: Building Applications Without Access to Raw Data
- Distributed Programming without Data Access: An MPC Guide
- Beyond the Cloud: The Role of Secure Computation in Backend Architecture
- Modern Systems Design: Why Distributed Systems are Moving Toward MPC
- From Cloud Storage to Secure Computation: A Guide to MPC
- Data in Use Protection: How MPC Keeps Inputs Hidden from the Cloud
- Privacy-Preserving Computation: The Developer’s Answer to Data Liability
- Integrating MPC: Designing Distributed Systems Without Access to Underlying Data
- Multiparty Computation: Building Without Access to User Data

Since the advent of computers, we've been increasingly seeking how to make computers run faster, communicate with each other and handle vast amounts of data. Over time, developers have built up an arsenal of tools, techniques and methods in order to do these things more effectively. This know-how is now known as distributed systems.

Most computation that you execute is either done on a single machine or in a datacenter. In the case of a single machine, you are in control of what happens to the data and how it's used. When your program runs on a remote machine in a datacenter, you still technically control the data but must trust the datacenter provider's physical security measures to ensure your data remains secure. And when your program executes across multiple remote machines, possibly in several datacenters, you have to extend that trust across all these machines and facilities even though you ostensibly have control over your data. As an industry, we've spent the past 20-odd years building vast cloud-based architectures to give developers and companies access to substantial computing power. But the biggest tradeoff has been trusting these service providers with your data. Now, there's a better way to maintain control of your data while drastically reducing your dependence on these service providers: Multiparty Computation (MPC).

Multiparty computation enables you to write programs that are inherently distributed across several machines while ensuring each machine doesn't know the inputs into the program. MPC allows you to decouple where and how you perform computation from the need to store your data in the cloud. This goes beyond simply allowing you to store data wherever and however you choose—it even allows you to forgo storing any data altogether, giving your users more control over their own data while still enabling you to compute using that data.

## How MPC Works

MPC accomplishes this through an interactive process between the client (who owns the data) and the distributed set of machines that will perform the computation. The key steps are:

1. The client first encrypts their data locally using their own encryption mechanism. This ensures the client maintains control over their data.

2. The client then sends the encrypted data to the distributed machines that will perform the computation. At this point, the client can go offline—they're no longer directly involved in the computation.

3. The distributed machines, which you as the developer have pre-programmed with the agreed-upon function to compute, execute the computation on the encrypted data. They do this through a secure, interactive process among themselves, without ever having access to the unencrypted data.

4. Once the computation is complete, each machine sends its share of the encrypted results back to the client.

5. Finally, the client can decrypt the final result using their own decryption mechanism and make use of it as needed.

While the above flow shows multiple distributed machines, many practical implementations use just two parties (known as 2PC) - such as a client and a server - while maintaining the same security properties.

This MPC approach allows the client to maintain control over their data while still enabling computation to be performed on that data in a scalable, distributed manner. The client never has to relinquish their unencrypted data, and the distributed machines performing the computation never have direct access to the unencrypted inputs. This provides a privacy-preserving way to leverage distributed compute resources.

-----

#### Alternative version

MPC works by splitting trust across multiple machines instead of concentrating it inside a single backend.

At a high level, the flow looks like this:

1. The client first prepares their data locally before it ever leaves their device. In an MPC system, that usually means the input is encrypted, secret-shared, or otherwise transformed into a protected form suitable for secure computation.

2. That protected input is then sent to the set of machines that will perform the computation. Because the data has already been prepared locally, the client does not need to hand over raw plaintext to the network.

3. Those machines have already been programmed with the function to compute. They then run a secure protocol among themselves to evaluate that function on the protected inputs, without any one machine learning the underlying private data.

4. At the end of the protocol, the parties produce partial results that can be combined to reveal the final answer only to the authorized recipient.

5. That final result is then reconstructed and used by the client or application, depending on how the system is designed.

The important idea is that no single machine ever needs full access to the user’s underlying input in order for useful computation to happen. In a conventional backend, the service works by collecting plaintext data into the provider’s trust boundary. In MPC, that trust is split across the protocol and the participating machines instead.

That architectural shift is what matters for developers. The application still computes. The user still gets a result. But the system is no longer built around centralizing access to sensitive data in plaintext. Instead, developers define the function ahead of time and the network jointly evaluates it without any one party seeing the full input.

That is where the developer experience starts to change.

## The Developer Experience

As you can see, the architecture of an MPC network looks pretty similar to most backend architectures deployed on the web today.
The main distinction lies in *how* you actually go from a regular backend service to an MPC backend service.

As a developer implementing MPC, you're responsible for designing and writing the computation logic that will be executed across the distributed machines. This is the same function you pre-program into the MPC network as mentioned earlier. You'll use a specialized programming model or language designed for MPC, and your code will be compiled to run in a distributed, secure execution environment. You can choose to deploy and manage this infrastructure yourself or leverage third-party MPC services that provide the necessary tooling and runtime.

MPC allows you to offer scalable compute while ensuring privacy for your users. This approach has an immediate benefit: you no longer need to consider the storage and compliance costs for storing user data in your application architecture. This allows you to build scalable, privacy-first applications without sacrificing user experience or the safeguarding of user data.

----
#### Alternate version

As you can see, the architecture of an MPC network looks a lot like the kinds of distributed systems developers already work with on the web today.

The difference is not that MPC introduces some completely foreign kind of backend. The difference is in how the computation is expressed and executed. Instead of sending user data to a conventional backend where it exists in plaintext inside the provider’s trust boundary, developers define the computation in a form that can run across multiple machines without any one machine learning the underlying private inputs.

From the developer’s perspective, this means writing the logic that will be executed by the MPC network itself. In practice, that usually means using an MPC-specific framework, language, or toolchain that compiles your program into a secure distributed execution flow. You are not just deploying a service across several machines. You are defining a function that those machines will jointly evaluate while keeping user data protected throughout the process.

That does change the development model. You may need to think differently about performance, state, data representation, and which parts of your application belong inside the MPC computation versus outside of it. But the payoff is meaningful: you can build applications that compute on sensitive user data without requiring your backend to collect and hold that data in plaintext.

That, in turn, changes the shape of the application architecture around it. If sensitive user data never needs to be centralized in plaintext on your servers, you can reduce what you need to store, replicate, secure, and account for from a compliance perspective. The result is a new developer experience: one where building scalable applications no longer has to mean taking custody of the very data your users most want kept private.

## The Future of MPC

MPC research has been ongoing for over 30 years, and many advances have been made to make it more accessible to developers. Adopting MPC requires you to think in a fundamentally new way while learning new tools: application development and systems design architecture without access to the underlying data, with communication costs as the main limiting factor. As users become increasingly aware of how their data is being used across their favorite internet services, the tradeoffs involved in building applications with MPC are becoming increasingly worthwhile.