Private Shared State (MPC + ZK / co-SNARKs)

Enable N parties to jointly read and write shared on-chain state (balances, positions, order books, collateral pools) while keeping each party's individual data private from the others and from the infrastructure operator. This variant secret-shares each party's inputs across a distributed prover network; the nodes jointly run an MPC protocol to compute a single zero-knowledge proof of a correct state transition; the proof is posted on-chain for verification.

Works best when

  • Multiple institutions share a ledger, pool, or order book and must hide individual positions from each other.
  • Cryptographic privacy guarantees are required (no hardware trust acceptable).
  • Regulatory audit must be possible without exposing raw data to all participants.

Avoid when

  • Single-party privacy is sufficient (use shielding instead).
  • Sub-second latency is critical (MPC rounds plus proving add batch latency).
  • Fully trustless client-side proving with no external infrastructure dependency is required.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions, the MPC node set is typically operated by the consortium members themselves or by a neutral third party under SLA. Honest-majority risk is bounded by bilateral agreements and audit logs; legal recourse backs any collusion claim.

Institution to end user

I2U

For user-facing deployments the prover and MPC node set must be operator-diverse and ideally permissionless. A user has no recourse if a coalition silently reconstructs their witness. Economic bonding with slashing and publicly auditable proving logs are required to make the guarantee meaningful.

Post-quantum exposure

Risk · high
Vector
Pairing-based SNARKs (Groth16, PLONK/KZG) broken by CRQC. MPC communication inherits the underlying key-exchange assumptions; HNDL risk applies to recorded MPC transcripts.
Mitigation
co-STARK alternatives with hash-based commitments. See Post-Quantum Threats.

Components

  • Secret-sharing layer splits each party's inputs (additive or Shamir) and routes shares to the proving network.
  • Distributed prover network jointly runs the MPC protocol to compute a zero-knowledge proof without any node reconstructing the full witness.
  • Coordinator sequences MPC rounds and assembles the final proof.
  • Commitment scheme (Pedersen, Poseidon) represents the shared state as commitments anchored on-chain.
  • On-chain verifier contract checks the proof and advances the state root on L1 or a settlement L2.
  • Regulatory disclosure path produces selective zero-knowledge proofs or scoped viewing material for auditors without revealing other participants' data.

Protocol

  1. user Each participating institution secret-shares its inputs across the MPC prover network.
  2. user A party submits a secret-shared state transition request (transfer, trade, margin call).
  3. prover MPC nodes jointly execute the co-SNARK protocol, exchanging shares across rounds to compute witness polynomials and commitments without reconstructing any plaintext.
  4. prover The coordinator assembles the final zero-knowledge proof and the new state commitment.
  5. contract The on-chain verifier checks the proof and advances the state root.
  6. auditor Regulator obtains scoped disclosure via a selective zero-knowledge proof or viewing key bound to a specific position.

Guarantees & threat model

Guarantees:

  • Input privacy: no party or MPC node learns another party's balances, positions, or trade intent under the honest-majority assumption.
  • State correctness: the on-chain zero-knowledge proof enforces that every transition follows protocol rules.
  • Settlement finality anchored to Ethereum L1 or an L2 for irreversibility.
  • Scoped auditability through selective zero-knowledge proofs or disclosure keys.

Threat model:

  • Soundness of the underlying SNARK and any trusted-setup ceremony.
  • Honest-majority assumption across MPC nodes. A colluding majority can recover witnesses and, in some constructions, forge proofs.
  • Non-censoring coordinator. A malicious coordinator can refuse to finalize or selectively drop requests; liveness fails, not privacy.
  • Authenticated and confidential channels between nodes. Metadata about participation and timing is out of scope.
  • Sender and receiver addresses are not hidden by default; address unlinkability requires composition with stealth addresses.

Trade-offs

  • Heavy communication overhead. Round count and bandwidth scale with both the number of provers and circuit size.
  • Batch latency of several hundred milliseconds to seconds per transition; batched throughput in the low hundreds of TPS in current research stacks.
  • Liveness depends on all designated nodes remaining online through the proving session. Dropouts force a restart.
  • New infrastructure requirements: MPC nodes, share routing, key management, and slashing if bond-backed.
  • Not a fit when sub-second latency is required or when a fully client-side proof is possible.

Example

  • Three banks share a tokenised-bond collateral pool on an Ethereum settlement L2. Each bank's deposit is secret-shared across the MPC prover network. A margin call triggers a joint co-SNARK run: the network produces one zero-knowledge proof attesting that aggregate collateral covers the exposure without revealing any individual position. The proof and the new state commitment are posted on-chain. A regulator later audits one bank's position via a scoped selective proof without learning the others.

See also

Open-source implementations