Skip to main content
Use this page after the basic backend decision is clear and the next question is how to shape the work that runs inside MPC. For backend selection, start with MPC Backends. For config, bytecode, local runs, and network execution, use How Backend Selection Works. For backend-specific examples, see HoneyBadgerMPC and AVSS. This page focuses on the cost model behind those choices: what becomes secret-dependent work, which type choices change preprocessing demand, and how HoneyBadgerMPC circuit costs differ from AVSS transcript costs.

​
Backend cost model

​
Circuit-shaping checklist

For both backends:
  • Count secret-dependent operations first. Public constants, hashes, encodings, and normalization factors should usually be computed outside the MPC circuit.
  • Distinguish total operation count from dependency depth. Independent work can often be batched or planned together; long dependent chains create extra interactive layers.
  • Prefer public parameters when they are not part of the private input. Public coefficients usually make a private weighted computation cheaper than secret coefficients.
  • Treat comparisons, bit-level logic, and nonlinear functions as expensive until measured. They often compile into more field operations than the source code suggests.
  • Size network/runtime configuration for the largest expected input shape, not the happy-path demo input.

​
Type choices and preprocessing demand

Types affect preprocessing demand because they influence which VM and share operations the compiler emits:
  • Clear/public values stay local. Public int64, fix64, bytes, curve names, constants, hashes, and encodings should remain clear until a secret operation actually needs them.
  • Secret values enter the MPC circuit. secret int64, secret bool, fixed-point shares, and Share values can consume preprocessing when an operation requires interaction.
  • Public weights are cheaper than secret weights. A private score with public coefficients is mostly share × clear-scalar work; making the coefficients secret turns those terms into secret × secret multiplications.
  • Fixed-point addition is usually close to integer share addition, but fixed-point multiplication can require extra scaling, truncation, or rounding logic. Use fixed-point where the application needs it, but avoid secret fixed-point products when a clear scaling factor is enough.
  • secret bool, comparisons, range checks, and bit decomposition are often larger than they look. A single source-level comparison can expand into many lower-level field operations.
  • Containers multiply the cost of their element operations. A list[secret int64] is not expensive by itself; a loop that multiplies each element by another secret value consumes work per element.
  • Width matters for low-level share helpers. Operations over 64-bit ranges generally require more bit work than the same operation over an 8- or 16-bit domain, so use the smallest safe width when writing explicit comparison or bit-decomposition code.
For AVSS, the important type question is whether the value is really a cryptographic scalar that needs a public commitment or curve-compatible output. If the value is ordinary application data and the output boundary is an opened result or client-output shares, start with HoneyBadgerMPC unless the application specifically needs AVSS commitments or curve compatibility.

​
HoneyBadgerMPC preprocessing intuition

HoneyBadgerMPC programs consume preprocessing primarily when they multiply secret shares or execute operations that compile into secret multiplications. Use preprocessing warnings as a signal to inspect the circuit shape:
  • Count secret × secret multiplications first. Additions, subtractions, and share × clear-scalar operations are usually local share operations; they should not drive triple demand the way secret multiplication does.
  • Separate multiplication count from multiplication depth. More independent multiplications mainly require more preprocessing material. Long dependent chains also increase the number of interactive multiplication layers, so they affect latency as well as total demand.
  • Batch independent work. Prefer vector/matrix-style loops where independent products can be planned together, rather than serializing products through an accumulator when the math does not require it.
  • Move clear work out of the MPC circuit. Precompute public constants, lookup tables, hashes, encodings, and normalization factors before they become secret-dependent values.
  • Replace secret × secret products with share × clear-scalar operations when one side is public. For weighted computations, keep coefficients public when they are not part of the private input.
  • Be careful with comparisons, bit decomposition, and nonlinear functions. They compile into many field operations and often dominate preprocessing demand more than the top-level source code suggests.
  • If the circuit is already appropriate, increase preprocessing capacity in the network configuration. Treat .preprocessing(multiplication_count, random_count) as a budget for the backend material the run can consume, and size it with headroom for the largest expected input shape.

​
AVSS transcript-shaping intuition

AVSS uses scalar shares and public commitments. The optimization target is usually the cryptographic transcript, not a generic multiplication budget:
  • Keep public transcript work public. Message encoding, domain separators, curve names, public keys, and transcript hashes should usually stay as clear bytes/fields until a secret scalar operation actually needs them.
  • Use Crypto.hash_to_field(..., Mpc.curve()) at the boundary where public transcript data becomes a curve-field challenge. Avoid turning public transcript material into secret shares earlier than necessary.
  • Persist long-lived key shares with LocalStorage instead of regenerating them on every run. For signing protocols, never persist or reuse per-signature nonces unless the protocol explicitly requires and protects that state.
  • Use commitments deliberately. get_commitment(0) gives the public group commitment associated with the scalar share; it is useful for public keys, nonce commitments, audit handles, and verification transcripts.
  • Minimize openings. Opening scalar responses or intermediate fields is sometimes part of a signature protocol, but unnecessary openings weaken privacy boundaries and add protocol work.
  • Choose the curve for the external protocol first. ed25519, secp256k1, p-256, bn254, and bls12_381 are not interchangeable when another system needs to verify a public commitment, encoded group element, scalar response, or signature-related artifact.
  • Do not use AVSS as a generic replacement for private arithmetic over ordinary application data. If the output boundary is an opened result or client-output shares, HoneyBadgerMPC is usually the better starting point.

​
AI-agent prompt shape

The canonical AI-agent workflow lives in Stoffel AI Agent Implementation. For performance-sensitive backend work, include the cost constraints below in the prompt. When using an AI coding agent, ask it to optimize around the same boundaries a human would inspect:
For docs or examples, require the agent to run stoffel check on StoffelLang snippets and npx mintlify validate before reporting completion.

​
See also