Skip to main content
Multi-Party Computation (MPC) lets several parties compute a result without first collecting every private input in one place. For an application developer, the important shift is the data form. In a usual stack, sensitive values are decrypted into ordinary application state so code can run. In an MPC stack, sensitive values are transformed into shares before they cross into the computation. MPC parties compute over those shares, exchange protocol messages, and reveal only the output the program explicitly opens or returns to the client.

​
What MPC changes

MPC changes where plaintext exists during computation. A normal application flow often looks like this:
That plaintext app state can then touch logs, databases, analytics tools, support systems, queues, caches, and downstream services unless each layer is carefully constrained. An MPC flow is different:
The parties running the computation do not receive the full plaintext input. They receive shares: pieces of the private value that are useful to the protocol but not meaningful on their own. MPC privacy flow showing input owners splitting private values into shares, MPC parties computing over shares, and only the opened result returning.

​
The core vocabulary

If you keep those nouns straight, the rest of MPC becomes easier to reason about: what exists as plaintext, what exists as shares, which nodes hold which material, and where values are allowed to become visible.

​
What MPC parties see

An MPC party sees:
  • its own share of each private input;
  • the compiled computation it is supposed to run;
  • protocol messages from other parties;
  • output shares or opened values that the program authorizes.
An MPC party should not see the full private input just because it participates in the computation. That is the core security boundary. MPC is not magic privacy dust around an ordinary app server. It is a different execution model: move the sensitive part of the computation into a protocol where parties work over shares.

​
What computation over shares means

Some operations over shares are straightforward. For example, adding two shared values can often be represented as each party adding its local shares. Other operations require interaction. Multiplication, comparisons, conditionals over secret values, and many higher-level operations need protocol support. Parties exchange messages that let the computation advance without revealing the underlying plaintext inputs. A useful mental model:
This distinction matters for developers because private computation is not just normal code with encryption sprinkled on top. The shape of the program affects what the protocol has to do. For a deeper explanation of why multiplication needs protocol support, read Computing with Secret Shares - Introducing Beaver Triples.

​
Openings: where secrecy intentionally ends

An opening is not a bug. It is the point where the program intentionally turns a shared value into something visible. Good MPC program design is explicit about outputs:
  • Which result should become visible?
  • Who should receive it?
  • Is the output an opened value, output shares, or a client-consumable result?
  • Does the output itself reveal more than the application intends?
MPC protects inputs during computation. It does not automatically make every possible output safe. The application still needs to decide what should be revealed.

​
What this means in Stoffel

Stoffel packages this model into a developer workflow: The goal is not to hide every MPC concept. You still need to understand shares, parties, thresholds, and openings. Stoffel makes those concepts concrete in a compiler, VM, CLI, and Rust SDK instead of making every application team implement protocols from scratch.

​
What MPC does not remove

MPC narrows where sensitive plaintext exists during computation. It does not remove every security or product-design responsibility. You still need to design:
  • which values are private inputs;
  • which values are allowed to become outputs;
  • how outputs are delivered to the right client or system;
  • what metadata, timing, access patterns, logs, and deployment details may reveal;
  • which parties, thresholds, and backend assumptions match the application.
Use MPC to move the sensitive computation out of ordinary plaintext application state. Then design the rest of the system around that boundary.

​
Next steps

  • Why Stoffel?: how Stoffel turns MPC concepts into a development workflow.
  • Quick start: create a project, build bytecode, and run local MPC.
  • System architecture: see how app code, bytecode, VM parties, and MPC backends fit together.