What is Multi-Party Computation? - Stoffel Documentation

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:

user data -> decrypt to compute -> plaintext app state -> result

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:

user data -> shares -> MPC parties compute over shares -> authorized output

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

Term	Meaning
Plaintext value	The original value before it is protected. In a Stoffel application, this should stay at the app/client edge.
Share	A protocol value derived from plaintext. A single share does not reveal the full input by itself.
MPC party	A node that runs the protocol over shares. Parties hold shares, not complete plaintext inputs.
Threshold	The number of shares or parties needed for a protocol action, such as reconstructing or opening a value.
Protocol messages	Network messages parties exchange to evaluate operations that cannot be computed locally on one share.
Opening	The moment a secret-shared value is intentionally reconstructed or returned as an output.
Authorized output	A value the program is designed to reveal, either as an opened result or as output material returned to the client.

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:

share-local operations:     parties update their own shares
interactive operations:     parties exchange protocol messages
openings / outputs:         selected values become visible by design

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:

MPC concept	Stoffel surface
Computation	StoffelLang source (`.stfl`)
Build artifact	`.stflb` bytecode
Local development	`stoffel check`, `stoffel build`, and local MPC runs
Parties	Local or networked Stoffel VM parties
Private values	Shares passed through the MPC runtime
Outputs	Explicit openings or client outputs defined by the program

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.

Why should I care about Multiparty Computation?: the broader case for MPC as a privacy-first application architecture.
Introduction to Secret Sharing from First Principles: build intuition for shares, thresholds, and reconstruction.
Computing with Secret Shares - Introducing Beaver Triples: why private multiplication uses protocol support such as Beaver triples.

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.

​What MPC changes

​The core vocabulary

​What MPC parties see

​What computation over shares means

​Openings: where secrecy intentionally ends

​What this means in Stoffel

​What MPC does not remove

​Related reading

​Next steps