> ## Documentation Index > Fetch the complete documentation index at: https://docs.stoffelmpc.com/llms.txt > Use this file to discover all available pages before exploring further. # What is Multi-Party Computation? > A developer mental model for MPC: plaintext becomes shares, parties compute over shares, and only explicit outputs become visible. 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: ```text theme={null} 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: ```text theme={null} 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: ```text theme={null} 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](https://stoffelmpc.com/stoffel-blog/beaver-triples-tuples). ## 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. ## Related reading * [Why should I care about Multiparty Computation?](https://stoffelmpc.com/stoffel-blog/intro-to-mpc): the broader case for MPC as a privacy-first application architecture. * [Introduction to Secret Sharing from First Principles](https://stoffelmpc.com/stoffel-blog/guide-to-secret-sharing): build intuition for shares, thresholds, and reconstruction. * [Computing with Secret Shares - Introducing Beaver Triples](https://stoffelmpc.com/stoffel-blog/beaver-triples-tuples): why private multiplication uses protocol support such as Beaver triples. ## Next steps * [Why Stoffel?](./why-stoffel): how Stoffel turns MPC concepts into a development workflow. * [Quick start](../getting-started/quick-start): create a project, build bytecode, and run local MPC. * [System architecture](../architecture/system): see how app code, bytecode, VM parties, and MPC backends fit together.