Works best when
- A user or institution lacks the compute, memory, or battery to generate a zero-knowledge proof client-side and wants to offload the work without disclosing the witness.
- The delegatee set can be run by independent operators so no single party sees the full witness.
Avoid when
- Client-side proving is feasible and low-latency is critical.
- Only one proving node is available (no honest-majority distribution possible); use a TEE-based prover instead.
I2I vs I2U — context differences
Institution to institution
I2IBetween institutions, delegated proving is typically contracted between known parties with SLAs and legal recourse. The prover set can be small and stable. Honest-majority risk is mitigated by bilateral agreements and audit logs.
Institution to end user
I2UFor users, the prover set must be permissionless or at least operator-diverse so that no coalition can recover the witness. Economic bonding with slashing and publicly auditable proving logs protect against collusion. A user has no recourse if the prover set silently leaks their witness.
Post-quantum exposure
Risk · high- Vector
- Pairing-based SNARKs (Groth16, PLONK/KZG) broken by CRQC. MPC communication inherits the underlying key-exchange assumptions.
- Mitigation
- co-STARK alternatives with hash-based commitments. See Post-Quantum Threats.
Components
- User or application holds the witness and wants a proof generated without exposing the witness.
- Share-distribution layer splits the witness using secret-sharing (additive or Shamir) and routes shares to proving nodes.
- Distributed prover network runs the MPC protocol to jointly compute the SNARK. Each node sees only its share.
- Coordinator sequences MPC rounds and assembles the final proof. Can be one of the proving nodes or a separate role.
- Verifier checks the final proof exactly as it would check a client-side SNARK. No changes on the verification side.
Protocol
- user Secret-share the witness across N proving nodes.
- prover Proving nodes jointly execute the co-SNARK MPC protocol, exchanging shares across multiple rounds to compute witness polynomials and commitments.
- prover The coordinator assembles the final proof from the MPC output.
- user Receive the assembled proof from the coordinator.
- contract A verifier contract (or off-chain verifier) checks the proof against the public statement.
Guarantees & threat model
Guarantees:
- The witness stays hidden from every individual prover and from the verifier.
- Verification cost is identical to a client-side SNARK for the same circuit.
- Preserves trade secrets, user balances, or model weights under honest-majority assumptions.
Threat model:
- Soundness of the underlying SNARK, including any trusted-setup ceremony.
- Honest-majority assumption across proving nodes. A colluding majority can recover the witness and, in some constructions, forge proofs.
- Non-censoring coordinator. A malicious coordinator can refuse to finalize or selectively drop requests.
- Authenticated and confidential channels between nodes. Metadata about participation and timing is out of scope.
Trade-offs
- Heavy communication overhead. Round count and bandwidth scale with both the number of provers and circuit size.
- New infrastructure requirements: MPC nodes, share routing, key management.
- Liveness depends on all designated nodes remaining online through the proving session. Dropouts typically force a restart.
- Latency is higher than client-side proving because of MPC round trips; not suitable for sub-second proving budgets.
Example
- A user holds a shielded balance and wants to prove a spend on a mobile device. The wallet secret-shares the spending witness across three independent proving operators. The operators jointly produce a Groth16 proof. None of them sees the balance or the spend amount. The user submits the proof to the shielded pool contract.