## Introduction

Private Proof Delegation (PPD) lets a resource-constrained client outsource the generation of a zero-knowledge proof to a more powerful server while keeping the client's private data (witness) confidential.

PPD is useful when proving overhead is too high and it’s impractical for the client to generate proof alone. This enables applications like confidential financial transactions, private model inference, and privacy-preserving authentication.

PPD is strongly related to _verifiable computation over encrypted data_ (VCoED), for which we have two competing paradigms:

- SNARK-FHE (applying SNARKs to prove FHE operations) aka vFHE,
- FHE-SNARK (homomorphically generating SNARK proofs) aka Blind SNARKs.

Given the fast pace of improvements in proof generation efficiency over the last years, unlike the more modest gains in FHE compute efficiencies, you may think the SNARK-FHE approach is more practical. In reality, the opposite trend is unfolding—new FHE-SNARK schemes offer orders of magnitude better performance: _12.3 ms per SNARK gate_ in the recent [FHE-SNARK paper](https://eprint.iacr.org/2025/302.pdf#page=4) vs[^1] _7000 ms per FHE bootstrapping_ via state-of-the-art [SNARK-FHE scheme](https://eprint.iacr.org/2025/261.pdf#page=16).

The reason why SNARK-FHE performs worse comes down to working with FHE in a _non-black-box_ manner. This is well explained in [Yuriko’s writeup](https://hackmd.io/rAiIvUadSWeI5oMgGpjorw?view#Problem-GGW23-tried-to-solve-non-black-box-use-of-FHE), but the gist is that FHE involves NTT and other non-linear “maintenance operations” like mod-switching, for which we lack efficient arithmetization techniques. In contrast, SNARK schemes that need no FFT/NTTs (e.g. GKR) and non-linear operations (e.g. FRI PCS) are extensively studied and developed.

The difference in performance raises another question: _do FHE-SNARK and SNARK-FHE offer equivalent security guarantees?_ [Zhang et al.](https://eprint.iacr.org/2025/302.pdf#page=3) establish that SNARK-FHE fits within the 2PC (2-party computation) model with fewer theoretical attacks than the purely VC (Verifiable Computation) model of FHE-SNARK. They show an input-dependent attack on FHE-SNARK when the server has private data used in the computation (before we get back to this attack assume that it’s a direct consequence of working with FHE as a black-box).

### This work

This document serves two purposes. First, we survey and analyze existing PPD schemes and related literature to answer the following questions:

1. _Given the performance vs security tradeoff between FHE-SNARK and SNARK-FHE, which approach is better for practical PPD deployments?_
2. _Which components and/or applications of PPD are currently under-explored or untested?_

Based on the answers to our questions, we propose several directions for advancing PPD research and development. **We aim to contribute to implementation and benchmarking efforts while exploring new cryptographic schemes for practical PPD under the Privacy & Scaling Explorations grant.**

## Technical Analysis: SNARK-FHE

### Ciphertext vs Plaintext Overhead

A surface-level distinction between both paradigms is that SNARK-FHE computes on ciphertexts (within the SNARK circuit) while FHE-SNARK on plaintexts (homomorphically within an FHE circuit). When both the FHE and SNARK components are treated as black boxes, distinguishing between the two doesn't matter. However, since SNARK-FHE requires non-black-box view on the composed FHE in the context of the external SNARK, it’s important to consider this difference and its implications.

FHE ciphertexts are cyclotomic ring elements of different often non-prime (but power-of-2) moduli; while SNARKs compute on field elements modulo some fixed prime. This necessitates simulating big integers and modulo reduction within a SNARK circuit aka [Non-native Field Arithmetic](https://hackmd.io/@JkY-zACaSqerTtn_UwFjKg/SJZw6x75o). While some proving systems, like Circle STARKs, handle this better than others, like Binius, all suffer from simulation overhead.

There’s an important tradeoff between the SNARK’s prime field size and big-int simulation overhead—bigger primes allow for less frequent modulo reductions by having bigger “overflow budget” but result in higher proving overhead as such big prime fields must be simulated on the CPU. Additionally, **different FHE schemes have different ring modulo sizes (BFV > FHEW) so some SNARK<>FHE scheme combinations would work better than the others, which is the important factor when designing SNARK-FHE schemes.**

Next, we summarize existing approaches and research directions to bridge the gap between SNARK and FHE native fields’ arithmetic.

#### **Range checks**

A standard method for simulating non-native field arithmetic employs range checks to constrain residue values, typically implemented through lookup arguments. The most important asymptotic complexity relation for lookups is between lookup table size $N$ and the number of queried values $m$.

Currently, only trusted setup EC-based lookup schemes (Caulk, CQ) provide table-intended prover work. However, these EC-based schemes, typically compiled to KZG, lack post-quantum (PQ) resistance, which is highly desired. Additionally, these schemes are rarely MLE-compatible, another important feature for proving SNARK-FHE. To our knowledge, **two state-of-the-art MLE-compatible lookup IOPs for range checks that can be compiled to PQ-resistant PCS are LogUp with O(m log m + N) prover work and Lasso O(m + N).**

#### Lattice-based SNARKs

An alternative approach is to use a SNARK scheme over the FHE’s native field, e.g. Lattice-based SNARKs like [LNP22](https://eprint.iacr.org/2024/1846.pdf) or [HSS24](https://eprint.iacr.org/2024/306).

[Atapoor et al](https://eprint.iacr.org/2024/032.pdf). chose [ISW21](https://eprint.iacr.org/2021/977.pdf) Lattice-based SNARK to prove BGV homomorphic operations. While ISW21 doesn’t operate over cyclotomic rings, *the double-CRT used in BGV to represent larger ring elements with smaller prime field elements that ISW21 can use.* Their construction demonstrated viability of SNARK & FHE co-design in regards to native arithmetic, but it suffered from a significant constraint blow-up when arithmetizing NTTs.

**Lattice-based SNARKs remain an attractive solution to bridge the gap in FHE and SNARK arithmetic for proving certain FHE components but can fall short when applied to proving the entire FHE construction, namely NTTs.**

A follow-up question is whether using multilinear (sumcheck-based) PIOPs known for efficient NTT proving together with a Lattice-based PCS could yield better results.

#### Zinc

We briefly mention [Zinc](https://eprint.iacr.org/2025/316)--a new hash-based succinct argument for integer arithmetic. This includes modular operations with any moduli, not necessarily prime, and possibly involving multiple moduli in the same statement. Their construction includes PIOP over rings and a Brakedown-type PCS.

Their work is still highly theoretical and it remains to be seen how its performance compares to state-of-the-art multilinear SNARKs with range checks and Lattice-based SNARKs. Nonetheless, **this work represents the closest internal arithmetic inner-working between SNARKs and FHE and holds a lot of potential for verifiable FHE.**

### Proving non-linear FHE operations

SNARKs operate on linear constraints by encoding computations as **low-degree polynomial relations** over a finite field. Non-linear operations like NTT, modulus switching, and accumulator updating in FHE introduce rounding errors, exponentiations, bitwise arithmetic, and structured transformations that don’t naturally map to this structure.

- **NTT** transforms polynomial coefficients into evaluation forms using structured _exponentiation_ patterns. The NTT algorithm’s efficiency comes from _parallelization, which cannot be leveraged by most SNARKs’ arithmetization_. Bit-reversal permutations in the Butterfly algorithm are tricky to constrain due to element swapping between slots.
- **Modulus switching** maps ciphertexts from a higher modulus $Q$ to a smaller modulus $q$ and involves _rounding_ that results in _errors due to precision loss and discontinuous functions_ that cannot be directly mapped on low-degree polynomial relations.
- **Accumulator updating**, a core component of bootstrapping, requires repeated _NTT and Hadamard products_.
- **Gadget decomposition** converts large numbers into smaller base representations, which can be recombined to reconstruct the original elements or their approximations. This involves _bitwise and big integer (CRT-based) arithmetic_.

In principle, we know which SNARK schemes fit to prove _particular_ FHE operations: Lookup-based range checks are indispensable in proving approximated and big integer arithmetic, though still usually account for the largest chunk of prover’s work. For bitwise-heavy programs, SNARKs over binary fields such as Binius and Hashcaster are obvious choices, but they are [notoriously](https://www.irreducible.com/posts/integer-multiplication-in-binius) hard to apply for big integer arithmetic, which is much easier on prime field schemes like Circle STARK. Lastly, data-parallel sumcheck interactive proofs, such as GKR, fit well for proving NTT/FFTs.

The main challenge is that vFHE involves _all_ “SNARK-unfriendly” operations, but not all SNARK schemes can work together. **The key issue is the choice of underlying field (prime, binary, and cyclotomic ring), as well as the impossibility to natively use different fields within the same prover.**

Next, we analyze the most recent attempt at achieving practical vFHE at scale.

#### HasteBoots

[HasteBoots](https://eprint.iacr.org/2025/261) is the new SNARK-FHE scheme that achieves 300x improvement over the previous [state-of-the-art](https://eprint.iacr.org/2024/451) in provable bootstrapping.

We briefly summarize their approach:

- **FHEW as underlying FHE scheme** due to its simple and proof-friendly bootstrapping, and a fixed modulo $q$ unlike BGV/BFV/CKKS with complex moduli towers.
- Careful choice of $q$ (power-of-2, FHE-friendly) and $Q$ (prime, SNARK-friendly) moduli satisfying $2 q \mid(Q-1)$ relation enables efficient **modulus lifting** ($q \rightarrow Q$) and **switching** ($Q \rightarrow q$) transformations, allowing to prove **accumulator update** natively in $\mathbb{F}_Q$.
- **Multilinear polynomials in sparse matrix representation to encode LWE ciphertexts** and **custom linear-time Sumcheck-based PIOPs to prove:**
- _Modulus lift_ via the **Schwartz-Zippel** trick to check a single random linear combination (RLC) query instead of NTT evaluation queries and **range checks (indexed lookup argument)**.
- _Accumulator update_: combination of many NTTs is **RLC** combined into a single instance proven via tweaked LogUp IOP to support a different set of roots of unity; **gadget decomposition** via **range checks**, and Hadamard that naturally translates to the **sumcheck protocol.**
- _Modulus switch_ via structured map proved as Hadamard product **sumcheck IOP** and range checks.
- _Homomorphic operations (LWE addition)_ in $\mathbb{F}_q$ remain to be simulated over $\mathbb{F}_Q$ using sumcheck and **range checks**.


Compared to previous state-of-the-art, HasteBoots’ efficiency gains result from using **_tailored_ sumcheck-based PIOP over a _general-purpose_ SNARK** (Plonky2). This leads to a linear-time prover for most FHE operations, and magnitudes better concrete performance and memory efficiency.

The choice of Brakedown-based PCS is another important factor. While fast in proof generation, it results in _longer verification times (300ms) and larger proof sizes (150MB!)._ In comparison, previous construction has an 8ms verifier and 200KB proofs.

Notably, _while the choice of prime and cyclotomic ring fields is one of the key contributions of HasteBoots, it hasn’t had as significant of an impacted performance_ as one could expect based on our previous section’s conclusion. We say it didn’t because the _accumulator update_—a part that is proven in the SNARK’s native prime field—remains the main bottleneck, accounting for over 90% of prover time.

This contradiction calls into question _whether SNARK-FHE co-design around field matching is a viable path forward for this field?_ The results of this and prior work suggest that **optimizing for simpler FHE bootstrapping, particularly in accumulator updating (e.g. fewer NTTs), or otherwise more efficient NTT or gadget decomposition IOPs could yield greater outcomes.** Yet, there are likely few “low-hanging fruit” optimizations left in those areas.

## Technical Analysis: FHE-SNARK

### Attacks on FHE-SNARK

Using FHE as black box opens several attack vectors in VC security model.

- **Input-Dependent Attacks** occur when a server modifies or chooses its input based on encrypted client data while still producing a valid proof.

Consider a sealed-bid auction, a client encrypts their bid $m$ and sends $\operatorname{Enc}(m)$ to the server, which must verifiably compare it against its own bid $w$. A malicious server, instead of using its honest bid, homomorphically computes $w^{\prime}=\operatorname{Enc}(m+1)$, so it always bids slightly higher than the client.

Input-dependent attacks work by breaking knowledge soundness of FHE-SNARK. The standard mitigation strategy is to require the server to commit to their private inputs in advance. Other input constraint strategies may apply depending on the application, but **the server must always perform some extra work to demonstrate knowledge soundness**. However, _if the server’s private input is not large, this extra work is negligible for our analysis._

The following attacks are not unique to FHE-SNARK but common to FHE due to its inherent malleability. While these attacks haven’t been confirmed for FHE-SNARK, no extensive studies exist on this subject to date.

- **Fault-and-Reaction Attacks** can be mounted by a server by introducing _safe-errors,_ like incorrect values, in FHE computation. For some secret values, this fault has no effect on the final result, and for others, it changes the result completely. By observing the client’s _reaction_, the server can infer the secret value targeted by the attack. See [Chillotti et al.](https://eprint.iacr.org/2016/1164.pdf#page=9) report for an example attack.
- **Malleability Attacks** exploit FHE’s inherent malleability: If an adversary has a valid ciphertext $\operatorname{Enc}(x)$, they can derive another valid ciphertext $\operatorname{Enc}(x^{\prime})$ where $x^{\prime}$ is related to $x$.
Suppose a server computes a proof $\pi_A$ for a correctly evaluated function over encrypted inputs. An attacker, leveraging FHE's malleability, transforms $\pi_A$ into $\pi_B$, for a related but different statement, potentially letting them forge valid proofs for unintended computations.

It may seem that since an FHE-SNARK client expects an encrypted proof which is either valid or not, it would be easy to detect a fault-and-reaction attack. However, it’s important to consider that reaction-based attacks since [Chillotti et al.](https://eprint.iacr.org/2016/1164.pdf#page=9) have become more [real](https://thomas-plantard.github.io/pdf/ZhaPlaSus11.pdf) and [practical](https://eprint.iacr.org/2022/1563), allowing the server to remain discreet. At the same time, SNARKs are inherently probabilistic so there’s always “negligible” probability of soundness error that an active adversary may exploit to mount a fault-and-reaction attack.

**It’s crucial not to treat FHE-SNARK as a composable security system, in the same way as a _potentially_[^2] UC-secure SNARK-FHE, so not to be tempted to relax some of the security parameters of the underlying SNARK (e.g. number of FRI queries).** _Further research into reaction and malleability based attacks on FHE-SNARK applications is needed._

### Public verifiability of FHE-SNARK

FHE-SNARK only gives us _privately verifiable_ SNARK since obtaining a homomorphically computed proof requires the FHE decryption key, meaning only the key holder (client) can validate the proof. This limits its application for PPD, namely in decentralized trust systems and multi-party computation setups.

A solution is to use **Proof of Decryption (PoD)**, which lets the verifier publicly prove that a decrypted proof corresponds to a valid encrypted proof, enabling public verification without revealing the decryption key.

However, PoD introduces new issues:

1. **New trust assumption** that the decryption proof itself is not selectively withheld or manipulated.
2. **Key recovery with decryption-oracle attacks.** For many FHE schemes, direct access to decryption outputs (a publicly verifiable proof) is equivalent to knowing a portion of a secret key as it gives a linear equation with the secret key vector. With repetition, the adversary [obtains](https://eprint.iacr.org/2024/127.pdf#page=2) an invertible system of linear equations and can recover the secret key.
3. Increase in **proof size and verification time**.
4. **Computational overhead** for the client (to generate a decryption proof).

#### How can PoD be manipulated?

1. If PoD doesn’t bind to the homomorphically computed SNARK ciphertext, an attacker could swap out a valid PoD from another proof, making verification unsound.
2. If PoD scheme is malleable, an adversary may **alter an existing PoD** to make it appear as if a different encrypted proof was valid.

First, we argue that in PPD applications, it’s generally not in the client’s interest to withhold (Issue 1) the proof they outsourced and potentially paid for to the server.

We suggest Issue 2 can be counteracted with a tweak in PoD circuit design—by applying proof composition (PCD/IVC) to hide the original proof, revealing only its validity. This lets us keep the proof size and verification time constant while combining two or more proofs, addressing Issue 3. As well as Issue 1.2, given a PCD circuit binds SNARK ciphertext $\operatorname{Enc}(\pi)$ to $\operatorname{Verify}(\pi)=0$ assertion.

To ensure the knowledge soundness of PoD (see [formal definition](https://eprint.iacr.org/2024/1684.pdf#page=25)), the decryption circuit must verify decryption with respect to a **committed secret key aka FHE decryption key.**

## Real-World Applications

Generating proofs for complex statements is resource-intensive, often untenable on devices with limited processing power and memory, like mobile phones, which limits application scope. This section analyzes how SNARK-FHE and FHE-SNARK approaches fit into the current real-world application landscape.

We start by listing application categories:

- **Financial applications:** confidential transactions, private data blockchain coprocessors, contingent P2P payments.
A single client has private witness and wants to generate proof that conditionally triggers an outcome on a public blockchain.
*Examples:* private payment apps, [shielded asset bridging](https://forum.namada.net/t/private-bridge-protocol-design-rationale-constraints-and-brainstorming/71), and [private data marketplaces](https://www.privatemarket.dev/whatisthis).
- **Data and ML:** Federated ML, Collaborative Data Analysis, and Privacy-Preserving Surveys.
Many clients have valuable private inputs that a server wants to verifiably compute on.
*Examples:* provably bias-free AI models, publicly verifiable private medical data research.
- **Private AI Inference:** A single client has private inputs and needs a proof of their correct evaluation of the specific public/private model.
- **Private credentials authentication:** A client has private credentials input to produce authentication proof with zero-knowledge guarantees.
*Examples:* Face-ID proof, Proof of Passport.

Note, this doesn’t include applications using verifiable delegation of _generic_ computation, where proof is to convince the client of correct computation ie., public verifiability is optional.

Among these applications, several key bottlenecks stand out:

- **Cryptography:** signatures, commitments, Merkle trees. (Financial applications)
Involves non-native arithmetic (Secp signatures), bitwise hashes (SHA256), complex algorithms (Bilinear pairing).
- **Bitwise, Integer, and Approximate arithmetic.** (Data, ML, AI Inference)
All are examples of non-native arithmetic where boolean, integer, float numbers and operations (XOR, modulo, rounding) must be simulated using prime field elements.
- **Complex data types:** Video, Photos, 3D, Regex. (Contingent payments, Authentication)
Many challenges, notably data conversion and parsing, conditional logic, variable length loops, etc.

With SNARKs alone, we typically address these bottlenecks with workarounds (algebraic hashes instead of bitwise ones), tailored proof systems (HashCaster, Zink), or extensive use of lookup arguments (range checks, precomputed tables).

But combined with FHE, tailoring the underlying scheme (e.g., SNARK) to application needs is no longer enough. Tailoring to the outer scheme (e.g., FHE) becomes more important, and we no longer have the same flexibility. Lookup arguments emerge as a more general solution.

And yet, **the use of lookup arguments in SNARK-FHE and FHE-SNARKs remains under-explored**, which _answers the second question of our analysis._

## Conclusion

Recall 3 key observations made earlier:

1. The viability of FHE-SNARK for PPD applications depends on the computation cost of knowledge soundness and public verifiability. It also suffers from reaction and malleability attacks that are under-explored.
2. SNARK-FHE has better security guarantees but its performance is bottlenecked by the bootstrapping sub-algorithm proved natively over prime fields, and the upside of FHE-tailored proof systems is getting limited.
3. Many PPD applications rely on lookup arguments, yet their use in SNARK-FHE and FHE-SNARK schemes is under-explored.

### SNARK-FHE vs FHE-SNARK

**SNARK-FHE**, aka vFHE, has long been a topic of research fueled by the [promise](https://eprint.iacr.org/2024/1207.pdf) to solve many FHE security issues, like reaction and malleability attacks. In PPD applications, it preserves these security guarantees, but its viability remains questionable: While the latest construction (HasteBoots) proves a single bootstrapping operation in 4s, FHE alone performs [~150 operations/second](https://eprint.iacr.org/2023/958) and we still yet to see its practical deployments for large circuits. By optimizing prover time, HasteBoots traded verification time (300ms) and proof size (150MB), which is impractical for many applications.

Being longer on researchers’ radar means many optimizations to SNARK-FHE performance are already explored. New FHE-tailored SNARKs are unlikely to bring as significant gains as HasteBoots scheme did. New FHE schemes might be more proof-friendly, but that’s out of this research’s scope.

**FHE-SNARK** approach is still nascent and largely unexplored. Since inheriting FHE’s attack vectors, it has weaker security guarantees that cannot be fixed by a composed SNARK. While it achieves excellent prover performance on a remote server, it requires the client to generate Proof of Decryption for public verifiability, potentially hindering its usefulness. The upside is that if we can address these issues, FHE-SNARK could offer a more scalable and practical PPD construction as it avoids proving non-linear FHE operations.

Although achieving SNARK-FHE remains an important goal and holds significant potential for future applications, **we conclud that there are currently more opportunities in exploring FHE-SNARK.**

### Future work

Based on current analysis, we identify research and implementation goals for our next proposal:

- **Deeper analysis of reaction, malleability, and other attacks on FHE-SNARKs**
Suggest mitigation strategies and their impact on performance and viability of this approach.
- **Practical use of lookup arguments in FHE-SNARKs**
Due to FHE’s non-linearity concerns, we will focus on sumcheck-based schemes, LogUp and Lasso.
- **Performance and soundness improvements to PoD**
Explore alternative proof systems for PoD and practically demonstrate how PCD/IVC addresses FHE-SNARK security issues, like decryption-oracle attacks.
- **SNARK-FHE with [Zinc](https://eprint.iacr.org/2025/316)**
Explore how Zink’s ability to support arbitrary field moduli can be leveraged to prove FHE.

[^1]: This SNARK-FHE scheme targets the TFHE scheme, which is unleveled and requires costly bootstrapping after a certain number of addition gates and nearly every multiplication gate. So although comparing _ms/gate_ to _ms/bootstrapping_ isn't entirely equivalent, it illustrates the significant performance gap.

[^2]: [Zhang et al.](http://eprint.iacr.org) demonstrate that SNARK-FHE can provide UC-equivalent security (secure under composition) by being equivalent to a standard malicious 2PC protocol.

## Appendix

Verifiable Computation over Encrypted Data (VCoED) offers one solution to the problem that PPD attempts to solve. This section compares VCoED to a few alternative approaches: Client-Side Proving, Collaborative (co)SNARKs, and Delegated Holographic SNARKs.

### PPD vs Client-Side Proving

Client-side proving enabled by “mobile-friendly” proof systems is a good option when a proof statement isn’t large. This already includes financial applications like Zcash, Aztec, Payy. It’s also true that mobile hardware is becoming more capable and larger statements will become practical over time.

This partly misses the point of proof delegation, as it allows greater flexibility in managing private witness. A client could encrypt larger reusable witness data beforehand and share it with the server for future proof delegations. Additionally, private witness can be provided by multiple parties _(private shared state),_ which can’t be done with client-side proving.

### VCoED vs CoSNARKs

CoSNARKs use MPC to generate proofs over secret-shared witness. This approach is generally more practical than FHE, but may suffer from high communication overhead. MPC use comes with weaker trust assumptions, at best t-out-of-n honest majority. **VCoED (SNARK-FHE or FHE-SNARK) is a good alternative for applications where higher computation cost is worth better trust assumptions.**

A special case is proof delegation with _private shared state_. In FHE, the party who holds the decryption key owns the entire private state. To mitigate this, the FHE decryption key can be secret shared for threshold FHE decryption. This way, no single party can decrypt the private shared state or the FHE computation result. While it works, this leads to the same trust assumptions as in CoSNARK MPC.

To complicate things again, computing a CoSNARK over private shared state is significantly harder than for a single client’s private witness, creating larger communication overhead. So, **whether to use CoSNARKs or VCoED for private shared state proof delegation boils down to comparing MPC communication overhead to FHE computation overhead.**

Not every VCoED\-based proof delegation requires threshold decryption to secure private shared state though. _If the resulting proof is a_ **_(zk)_**_SNARK that doesn’t expose privately shared inputs, it suffices if one party owns the FHE secret key and volunteers to generate the final PoD._ An example is a private inference where the server owns a private model.

### VCoED vs Delegated Spartan

An alternative to CoSNARKs is a delegated proving model built on Holographic PIOPs such as Spartan, which lets us offload the heaviest part of proving to an untrusted party while keeping the witness private.

In Spartan, the proving process is split into three steps:

1. Reducing R1CS relation to polynomial claims (relatively light for the prover).
2. Proving the witness polynomial evaluation (relatively light for the prover).
3. Proving sparse polynomial evaluations (the heaviest part, taking 90%+ of the work).

The key insight is that soundness and zero-knowledge can be achieved after a single sumcheck round together with proving witness polynomial evaluation. The latter rounds involving expensive sparse polynomial evaluation can be offloaded to an untrusted server without them ever seeing the witness polynomial. It’s also possible batch multiple client proofs for further cost amortization.

Limitations:

- Witness polynomial evaluation cost grows with the circuit size, so there is an upper bound of what client can prove efficiently on-device. To tackle this, Worldcoin intends to use WHIR for evaluation proofs, citing best client-side performance and small proofs.
- No support for private shared state; only one party who owns the witness runs first sumcheck round and witness evaluation.

While being very elegant and simple, at the movement this approach is least analyzed and lacks formal definition. Given the limitations above, **VCoED remains relevant for large circuits and private shared state.** However, the details surrounding this trade-off are still unclear:

- Beyond which circuit size does FHE-SNARK based PPD outperforms delegated Holographic PIOPs?
- Various details around private shared state in FHE-SNARK (approaches, cost).

We intend to answer this question in our future work.

*[PPD]: Private Proof Delegation
*[PCD]: Proof-Carrying Data
*[IVC]: Incrementally Verifiable Computation
*[PCS]: Polynomial Commitment Scheme
*[vFHE]: Verifiable FHE
*[VCoED]: Verifiable Computation over Encrypted Data
*[PoD]: Proof of Decryption (of FHE computation result)
*[RLC]: Random Linear Combination
*[UC]: Universal Composition