Title: Delegated Proving (co-SNARKs) · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-co-snark/

Markdown Content:
---
description: Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is identical to one produced client-side and is verified on-chain or off-chain with no changes on the verifier side.
title: Delegated Proving (co-SNARKs) · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### 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

Between 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.

For 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.

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](../domains/post-quantum.md).

## 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

1. user Secret-share the witness across N proving nodes.
2. prover Proving nodes jointly execute the co-SNARK MPC protocol, exchanging shares across multiple rounds to compute witness polynomials and commitments.
3. prover The coordinator assembles the final proof from the MPC output.
4. user Receive the assembled proof from the coordinator.
5. 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.

## See also

* [Collaborative zk-SNARKs (Ozdemir & Boneh, 2021)](https://eprint.iacr.org/2021/1530.pdf)
* [TACEO private proof delegation](https://core.taceo.io/articles/private-proof-delegation/)
* [TACEO Merces vendor page](/vendors/taceo-merces/)

### Open-source implementations

* [ github.com Rust co-SNARK proving framework supporting Groth16 and PLONK (research/testnet) ↗ ](https://github.com/TaceoLabs/co-snarks)

CROPS profile

Censorship-resistance: mediumOpen source: yesPrivacy: fullSecurity: medium

CRCensorship-resistancemedium

Reaches `high` when the prover network is permissionless and bond-backed with slashing for Byzantine behaviour. Drops to `low` when a single proving service controls the pipeline.

OSOpen sourceyes

Proving-framework implementations are published under permissive licenses; production deployments may bundle proprietary orchestration.

PPrivacyfull

The witness stays hidden from each individual prover and from the verifier. Metadata about who requested a proof, when, and against which circuit can still leak.

SSecuritymedium

Rides on the soundness of the underlying SNARK and the honest-majority assumption of the MPC protocol. Trusted-setup requirements inherit from the SNARK (Groth16 needs per-circuit setup; PLONK/KZG uses universal setup).

#### Referenced by

approaches4
* [Private Bond Issuance & Trading](/approaches/approach-private-bonds/)
* [Private Identity](/approaches/approach-private-identity/)
* [Private Payments](/approaches/approach-private-payments/)
* [Private Smart Derivatives](/approaches/approach-private-derivatives/)
use cases2
* [Private Identity](/use-cases/private-identity/)
* [Private RWA Tokenization](/use-cases/private-rwa-tokenization/)
building blocks10
* [Blob-Anchored State With KZG Dispute](/patterns/pattern-blob-anchored-state-with-dispute/)
* [Hybrid TEE + ZK settlement](/patterns/pattern-tee-zk-settlement/)
* [Noir Private Contracts](/patterns/pattern-noir-private-contracts/)
* [Private Set Intersection (Circuit-based)](/patterns/pattern-private-set-intersection-circuit/)
* [Private Shared State (FHE)](/patterns/pattern-private-shared-state-fhe/)
* [Private Shared State (MPC + ZK / co-SNARKs)](/patterns/pattern-private-shared-state-cosnark/)
* [Private Shared State (TEE)](/patterns/pattern-private-shared-state-tee/)
* [Safe Proof Delegation](/patterns/pattern-safe-proof-delegation/)
* [TEE-Based Privacy](/patterns/pattern-tee-based-privacy/)
* [ZK Proof Systems](/patterns/pattern-zk-proof-systems/)
vendors2
* [Renegade](/vendors/renegade/)
* [TACEO Merces](/vendors/taceo-merces/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```